CN117850895A - Method and device for starting equipment based on boot loader and electronic equipment - Google Patents
Method and device for starting equipment based on boot loader and electronic equipment Download PDFInfo
- Publication number
- CN117850895A CN117850895A CN202410263773.2A CN202410263773A CN117850895A CN 117850895 A CN117850895 A CN 117850895A CN 202410263773 A CN202410263773 A CN 202410263773A CN 117850895 A CN117850895 A CN 117850895A
- Authority
- CN
- China
- Prior art keywords
- boot loader
- stage
- storage medium
- bootloader
- target
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 49
- 238000004590 computer program Methods 0.000 claims description 14
- 238000010586 diagram Methods 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Landscapes
- Stored Programmes (AREA)
Abstract
The embodiment of the application provides a method and device for starting equipment based on a boot loader and electronic equipment. In order to make the bootloader compatible with multiple types of storage media, a common multiple of the size of the minimum erasable unit of multiple types of storage media that need to be compatible may be taken as a storage address offset of the second bootloader, so that when the second-stage bootloader is stored in different storage media, the second-stage bootloader can be stored based on the storage address offset. Because the storage address offset recorded in the first stage boot loader is fixed for different types of storage media, namely the same first stage boot loader is adopted, the second stage boot loader can be loaded from different types of storage media accurately, one boot loader is compatible with multiple storage media, the cost is saved, and the starting of the device is more convenient.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method and an apparatus for starting a device based on a boot loader, and an electronic device.
Background
During the device boot process, it is often necessary to rely on a Bootloader (Bootloader) to boot the operating system of the device. The boot loader is a special code pre-burned in a storage medium for starting an operating system, and generally comprises a first stage boot loader and a second stage boot loader, wherein the first stage boot loader is responsible for some basic hardware initialization and configuration, and loads the second stage boot loader into an external memory connected with the SOC chip, and the second stage boot loader is responsible for further initializing hardware devices, loading files such as a kernel and a file system of the operating system, and starting the operating system.
In the related art, in order to enable the first stage boot loader to be successfully loaded into the second stage boot loader in different types of storage media, different boot loaders need to be compiled for different storage media types, and it is relatively complicated to implement that one version of boot loader is compatible with multiple storage media.
Disclosure of Invention
In view of the foregoing, the present application provides a method, an apparatus, and an electronic device for booting a device based on a bootloader.
According to a first aspect of the present application, there is provided a method for booting a device based on a bootloader, wherein the bootloader comprises a first stage bootloader and a second stage bootloader, the method comprising:
after detecting that the device is powered on, loading the first-stage boot loader from a target storage medium storing the boot loader, executing the first-stage boot loader to acquire a storage address offset of the second-stage boot loader, and loading the second-stage boot loader from the target storage medium based on the storage address offset;
executing the second stage boot loader to boot an operating system of the device;
wherein the storage address offset is an offset of a starting storage address of the second stage boot loader in the target storage medium relative to a starting storage address of the first stage boot loader in the target storage medium; the storage address offset is a common multiple of the sizes of respective minimum erasable units of at least two storage media compatible with the bootloader.
According to a second aspect of the present application, there is provided an apparatus for booting a device based on a bootloader, wherein the bootloader includes a first stage bootloader and a second stage bootloader, the apparatus comprising:
the loading module is used for loading the first-stage boot loader from a target storage medium storing the boot loader after the device is detected to be powered on, executing the first-stage boot loader to acquire the storage address offset of the second-stage boot loader, and loading the second-stage boot loader from the target storage medium based on the storage address offset;
the execution module is used for executing the second-stage boot loader to start an operating system of the equipment;
wherein the storage address offset is an offset of a starting storage address of the second stage boot loader in the target storage medium relative to a starting storage address of the first stage boot loader in the target storage medium; the storage address offset is a common multiple of the sizes of respective minimum erasable units of at least two storage media compatible with the bootloader.
According to a third aspect of the present application, there is provided an electronic device comprising a processor, a memory and a computer program stored in the memory for execution by the processor, the computer program when executed implementing the method mentioned in the first aspect.
According to a fourth aspect of the present application there is provided a computer program product comprising a computer program which, when executed by a processor, implements the method of the first aspect mentioned above.
According to a fifth aspect of the present application, there is provided a computer readable storage medium, characterized in that the computer readable storage medium has stored thereon a computer program which, when executed, implements the method mentioned in the first aspect.
By applying the scheme provided by the application, in order to enable the boot loader to be compatible with multiple types of storage media, the storage address offset of the second-stage boot loader when the second-stage boot loader is stored in the multiple types of storage media can be unified, namely, the storage address offset can be determined based on the size of the minimum erasable unit of the multiple types of storage media which need to be compatible at the same time, so as to adapt to the multiple types of storage media. For example, the storage address offset may be a common multiple of the size of the smallest erasable unit of the multiple types of storage media that need to be compatible, and when the second stage bootloader is stored, the second stage bootloader may be stored based on the storage address offset. When the first stage boot loader in the boot loader is compiled, the storage address offset recorded in the first stage boot loader is fixed for different types of storage media, so that the second stage boot loader can be accurately and successfully loaded from different types of storage media without compiling different first stage boot loaders, namely, the same first stage boot loader is adopted, one boot loader is compatible with multiple storage media, the cost is saved, and the starting of equipment is more convenient.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort to a person skilled in the art.
Fig. 1a is a schematic diagram of a related art boot loader stored in a storage medium.
Fig. 1b is a schematic diagram of a related art boot loader stored in a storage medium.
Fig. 2 is a schematic diagram of an embedded device using a uboot program to boot the embedded device.
FIG. 3 is a schematic diagram of a bootloader program stored in a storage medium according to one embodiment of the present application.
FIG. 4 is a flow chart of a bootloader-based launch device according to one embodiment of the present application.
FIG. 5a is a flow chart of a bootloader-based launch device according to one embodiment of the present application.
FIG. 5b is a flow chart of a second stage boot loader boot device boot up of one embodiment of the present application.
FIG. 6 is a schematic diagram of the logical structure of an apparatus of a bootloader-based launch device according to one embodiment of the present application.
Fig. 7 is a schematic diagram of a logic structure of an electronic device according to an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.
During the device boot process, it is often necessary to rely on a Bootloader (Bootloader) to boot the operating system of the device. The boot loader is a special code which is burnt in a storage medium for starting the operating system in advance, and has the main functions of initializing hardware equipment, loading operating system kernels, file systems, equipment file trees and other files related to the starting of the operating system into a memory so as to realize the starting of the operating system.
The bootloader typically includes a first stage bootloader, which is typically a very simple program stored in a fixed location on a storage medium, and a second stage bootloader, which has the main task of performing some most basic hardware initialization and configuration after the device is powered up or reset, and loading the second stage bootloader into memory. The second stage boot is typically a more complex program responsible for further initializing the hardware device, loading the kernel of the operating system, the file system, the kernel device tree, etc., and booting the operating system.
Typically, in order that the first phase bootloader may be loaded, the first phase bootloader has a fixed starting memory address in the storage medium, e.g. by default the starting address of the storage medium. And the storage address of the storage medium by the second-stage bootloader may be determined by an offset (hereinafter referred to as a storage address offset) of the start storage address of the storage medium by the second-stage bootloader relative to the start storage address of the storage medium by the first-stage bootloader.
In order to be able to load the second-stage boot loader from the storage medium, the first-stage boot loader has a storage address offset of the second-stage boot loader recorded therein. As shown in fig. 1a and 1b, in order to achieve flexible erasing and burning of the first stage bootloader and the second stage bootloader, typically, the first stage bootloader and the second stage bootloader are stored in different memory blocks (i.e., a minimum erasable unit, such as a sector, a page, or a block) of the storage medium, i.e., the memory address offset is an integer multiple of the minimum erasable unit size of the storage medium. For example, the memory address offset in FIG. 1a is the minimum erasable unit size of the storage medium, and the memory address offset in FIG. 1b is 2 times the minimum erasable unit size of the storage medium.
The minimum erasable unit size is different for different types of storage media, and the storage address offset recorded in the first stage boot loader is also different. Therefore, in the related art, in order to enable the first stage boot loader to successfully load to the second stage boot loader in different types of storage media, different boot loaders need to be compiled for different storage media types, and it is relatively complicated to implement that one version of boot loader is compatible with multiple storage media.
For example, taking the startup of an embedded device as an example, the embedded device typically needs to implement the startup of an operating system through uboot (a kind of bootloader). The image file (uboot image) of the uboot boot loader generally includes a two-stage boot loader, where the first stage boot loader is spl. As shown in fig. 2, a schematic structural diagram of an embedded device is shown, and when an operating system of the embedded device is started up through uboot, the general procedure is as follows:
first, an initialization boot program is pre-cured in an on-chip memory ROM in an SOC chip of the embedded device, where a start memory address of a first stage boot loader spl. Bin of uboot is recorded in an external storage medium for storing the uboot boot loader, where the start memory address is usually fixed, for example, is a start address in the external storage medium.
After the embedded device is powered on, the CPU reads the initialization program from the ROM into the on-chip SRAM, and the initialization boot program initializes the external storage medium and reads the first stage boot loader SPL. Bin of uboot from the external storage medium to run in the on-chip memory SRAM. After initializing the clock, the external DDR and the external storage medium, the uboot. Bin is read from the external storage medium into the external DDR.
The CPU runs the uboot.bin program, the uboot.bin program then completes the initialization of a hardware clock, the initialization of board-level hardware and the like, and then reads an operating system kernel, a file system and a device tree file from an external storage medium to an external DDR, and the starting of the operating system is guided.
The external storage medium may be various types of storage media, such as EMMC, nor Flash, nand Flash, etc., and the spl.bin program is loaded according to the storage address offset of the uboot.bin program when the uboot.bin program is loaded due to different sizes of corresponding minimum erasable units of different types of external storage media. Therefore, the same uboot.img is burnt into different memory media, and when the uboot.bin is loaded by the SPL.bin program, the phenomenon that the loading address of the partial starting media uboot.bin is not consistent is necessarily caused, so that the starting is impossible.
For example, the minimum erasable unit of the EMMC is typically 64K, the minimum erasable unit of the Nand Flash is typically 256K, and since the first stage bootloader spl.bin is relatively small and is typically stored in the first minimum erasable unit, for the EMMC, the offset of the starting memory address of the second stage bootloader uboot.bin relative to the starting memory address of the first stage bootloader spl.bin is 64K, and for the Nand Flash, the offset of the starting memory address of the second stage bootloader uboot.bin relative to the starting memory address of the first stage bootloader spl.bin is 256K, and since the offset needs to be compiled into the first stage bootloader spl.bin, it is necessary to compile different spl.bins for different storage mediums to record different offsets, otherwise, abnormal loading and starting of the spl.bin in different storage mediums may occur, which causes device starting.
Based on this, the embodiments of the present application provide a method for booting a device based on a bootloader, considering that in the related art, when storing the second stage bootloader in different storage media, the offset (hereinafter referred to as a storage address offset) of the start storage address of the storage media relative to the start storage address of the first stage bootloader in the storage media is determined based on the minimum erasable unit of the storage media, for example, the storage address offset is a multiple of the size of the minimum erasable unit, and the minimum erasable unit size of the different storage media is different, so the storage address offset is different, and therefore, it is necessary to compile different first stage bootloaders to record the storage address offset.
In order for the bootloader to be compatible with multiple types of storage media, as shown in fig. 3, the storage address offset of the second stage bootloader when stored in the multiple types of storage media may be unified, that is, the storage address offset may be determined based on the size of the minimum erasable unit of the multiple types of storage media that need to be compatible at the same time, so as to adapt to the multiple types of storage media. For example, the storage address offset may be a common multiple of the size of the smallest erasable unit of multiple types of storage media that need to be compatible, for example, as shown in fig. 3, the common multiple of the smallest erasable unit of three types of storage media, namely, storage medium 1, storage medium 2, and storage medium 3, may be taken as the storage address start offset, and when the second stage boot loader is stored, the second stage boot loader may be stored based on the storage address offset. When the first stage boot loader in the boot loader is compiled, the storage address offset recorded in the first stage boot loader is fixed for different types of storage media, so that the second stage boot loader can be accurately and successfully loaded from different types of storage media without compiling different first stage boot loaders, namely, the same first stage boot loader is adopted, one boot loader is compatible with multiple storage media, the cost is saved, and the starting of equipment is more convenient.
The method for starting the device based on the boot loader according to the embodiment of the application can be executed by a CPU in the device, and the device can be various devices which need to start an operating system by means of the boot loader. For example, in some scenarios, the device may be an embedded device and the bootloader may be a uboot program. Of course, for other types of devices, the bootloader may be other types of bootloaders, and embodiments of the present application are not limited.
The storage medium according to the embodiment of the present application may be various media that may be used to store the boot loader, for example, EMMC, nor Flash, nand Flash, hard disk, and the like.
The bootloader in the embodiment of the present application includes a two-stage bootloader, i.e., a first-stage bootloader and a second-stage bootloader, where the initial storage address of the first-stage bootloader in the storage medium is fixed and known, for example, the initial storage address of the storage space of the storage medium may be regarded as the initial storage address of the first-stage bootloader by default. After the device is powered up, the first stage boot loader may be loaded from the storage medium and executed to implement some basic hardware initialization and configuration, and the second stage boot loader may be loaded into memory. For example, taking the device as an embedded device, the bootloader is a uboot program, the first stage bootloader is spl.
In order to load the second stage boot loader, the first stage boot loader records a storage address offset of the second stage boot loader, where the storage address offset is a common multiple of the sizes of the minimum erasable units of at least two storage media compatible with the boot loader. For example, assuming that the bootloader is compatible with A, B, C three storage media, the minimum erasable units of the three storage media are 32K, 64K, 256K, respectively, the storage address offset may be a common multiple of 32K, 64K, 256K, such as 256K, 512K, 1024K, etc. The second stage bootloader may be stored in a different type of storage medium based on the storage address offset when the bootloader is compiled.
As shown in fig. 4, the method may include the steps of:
s402, after the device is detected to be powered on, loading the first-stage boot loader from a target storage medium storing the boot loader, executing the first-stage boot loader to acquire the storage address offset of the second-stage boot loader, and loading the second-stage boot loader from the target storage medium based on the storage address offset;
In step S402, after the device is detected to be powered up, the first-stage boot loader may be loaded from the target storage medium storing the boot loader, and since the initial storage address of the first-stage boot loader in the storage medium is generally fixed, the first-stage boot loader may be loaded from the target storage medium based on the fixed address.
For example, in most of the current devices, an SOC chip is adopted, a post-stage initial boot program is usually cured in the SOC chip, an initial storage address of a first stage boot loader in a storage medium is recorded in the initial boot program, and after the device is powered on, the SOC chip can load and run the initial boot program, that is, the first stage boot loader can be loaded from a target storage medium.
After loading the first stage boot loader into memory (e.g., SRAM), the CPU may execute the first stage boot loader to obtain a storage address offset for the second stage boot loader, and load the second stage boot loader from the target storage medium into memory based on the storage address offset.
Of course, when the first stage boot loader is executed, in addition to the second stage boot loader being loaded into the memory, some basic hardware initialization processing may be performed, such as initializing a clock, an external storage medium, and the like.
S404, executing the second stage boot loader to start an operating system of the device;
in step S404, after the second stage boot loader is loaded into memory, the second stage boot loader may be executed to boot the operating system of the device. For example, the second stage boot loader may implement initialization of a hardware clock, initialization of board level hardware, reading an operating system kernel, a file system, a device tree file, etc. from a target storage medium to launch the operating system of the device.
In some embodiments, given that first-phase bootloaders tend to be generally simpler, the amount of data is smaller, and therefore, they generally occupy only the storage space corresponding to one or a few of the smallest erasable units of the storage medium. If the storage address offset of the second stage boot loader is set to be too large, that is, there is more free storage space between the storage space of the first stage boot loader and the storage space of the second stage boot loader, resulting in the storage space being wasted, as shown in fig. 3, if the storage address offset is obtained to be large, the more storage space is wasted in the storage medium 1, the storage medium 2, and the storage medium 3. In order to meet the storage requirement of the boot loader on the storage medium, unify the storage address offset of different types of storage media, and minimize the waste of storage space, the storage address offset may be the least common multiple of the sizes of the minimum erasable units of at least two storage media compatible with the boot loader. For example, assuming that the bootloader is compatible with A, B, C three storage media, the minimum erasable units of the three storage media are 32K, 64K, 256K, respectively, the storage address offset may be the least common multiple of 32K, 64K, 256K.
It is considered that the first stage boot loader needs to perform an initialization process on the storage medium before loading the second stage boot loader from the storage medium, and the initialization parameters when performing the initialization process on different types of storage media are different. Thus, in some embodiments, for scenarios where the bootloader is compatible with multiple types of storage media, executing the first stage bootloader before loading the second stage bootloader from the target storage medium may also be used to: the method comprises the steps of obtaining the type of a target storage medium, obtaining initialization parameters matched with the type from the target storage medium, and initializing the target storage medium based on the initialization parameters. If the boot loader is compatible with multiple types of storage media, the function of obtaining the type of the target storage media, obtaining the matched initialization parameters based on the type of the target storage media, and initializing the target storage media is also needed to be configured in the first stage of the boot loader. The type of the target storage medium may be determined directly by the first stage boot loader, or may be stored after being determined by other boot loader, and then the first stage boot loader acquires the stored type. For example, an initialization program is usually pre-cured in the SOC chip of the device, and the initialization program can load the first-stage boot loader to the device memory for running when running, so that the initialization program can determine the type of the target storage medium and store the determined type of the target storage medium in a designated register, and then the first-stage boot loader can directly acquire from the designated register.
After the initialization operation on the target storage medium is completed, an operation of acquiring a storage address offset of the second-stage boot loader and loading the second-stage boot loader from the target storage medium based on the storage address offset may be performed. Considering that the second stage boot loader may also be different for different types of storage media and the types of object files associated with the operating system that it adapts to when the operating system of the device is started, in some embodiments, the following operations may be implemented when the second stage boot loader is executed to start the operating system of the device for scenarios in which the boot loader is compatible with multiple types of storage media: the method comprises the steps of firstly determining the type of a target storage medium, loading a target file matched with the type from the target storage medium, and starting an operating system of the device based on the target file, wherein the target file can be various files related to the starting of the operating system. The type of the target storage medium may be determined directly by the second stage boot loader, or may be stored after being determined by other boot loader, and then the second stage boot loader acquires the stored type. For example, the type of the target storage medium may be determined by a pre-cured initialization program in the SOC chip of the device or the first stage boot loader, and stored in a designated register, from which the second stage boot loader is subsequently directly retrieved. In some embodiments, the target file may be one or more of a device tree file, a kernel of an operating system, a file system. The device tree files adapted to different types of storage media are usually different, and the kernel and the file system of the operating system may be the same or different.
If the boot loader is compatible with multiple types of storage media, the second stage boot loader needs to be configured to determine the type of the target storage media, acquire various matched files for starting the operating system based on the type of the target storage media, and start the functions of the operating system based on the acquired files.
In general, for a scenario that a bootloader is compatible with multiple types of storage media, when compiling the bootloader, a user may select a type of storage media compatible with the bootloader, for example, it is assumed that the storage media compatible with the bootloader selected by the user are EMMC, norflash, nand Flash, and further when compiling the bootloader, respective corresponding initialization parameters of the three types of storage media and a file related to the starting of the operating system may be compiled into the bootloader, and the bootloader may be stored in the target storage medium, that is, the target storage medium stores the respective initialization parameters of the three types of storage media and the file related to the operating system. Thus, when executing the first bootloader, the first bootloader needs to acquire the type of the target storage medium currently in use, and acquire the initialization parameters matching the type based on the type of the target storage medium. For example, the target storage medium is EMMC, and the initialization parameter corresponding to the EMMC needs to be obtained from the target storage medium, and the EMMC is initialized based on the initialization parameter, so as to load the second stage boot loader from the EMMC. Similarly, when the second stage boot loader is executed, the second stage boot loader also needs to acquire the type of the target storage medium (for example, EMMC), so as to acquire a device tree file, an operating system kernel, and other files corresponding to the EMMC from the EMMC, and use the device tree file, the operating system kernel, and other files to start the operating system of the device.
In some embodiments, the device may include an SOC chip in which a GPIO (General-purpose input/output) interface may be configured, and different level signals may be configured in advance for different types of storage media for a scenario in which the bootloader is compatible with multiple types of storage media in order to determine the type of storage media currently used to store the bootloader. When the type of the target storage medium is determined, the type thereof can be determined by reading the level signal of the GPIO interface. For example, the level signal of the GPIO interface may include a high level and a low level, where the high level and the low level may be implemented by configuring different hardware resistors, for example, the pull-up resistor is usually connected to the power supply and is high, the pull-down resistor is grounded and is low, and the resistance value of the resistor affects the level. The type of storage medium can be distinguished by the difference in the level signal acquired from the GPIO interface.
For example, assuming that the bootloader is A, B, C three storage media compatible, three different level signals may be configured at the GPIO interface for A, B, C three storage media. Since the level signal captured by the GPIO interface has only a high level 1 and a low level 0, permutation and combination can be used to distinguish storage medium types. For example, for the above 3 storage medium types, two GPIO interface signals may be used to distinguish between, for example, 00 for an a storage medium, 01 for a B storage medium, and 10 for a C storage medium, although for more storage medium types, a similar approach may be used.
In some embodiments, the type of target storage medium may be implemented by different booths at different stages of device startup. For example, in general, device startup typically includes the following three phases: (1) An initialization boot program is usually solidified in an SOC chip of the device, and can load a first-stage boot loader from a target storage medium after the device is powered on; (2) Executing the first stage boot loader, then the second stage boot loader may be loaded from the target storage medium; (3) The second stage boot loader is then executed to boot the device operating system. Thus, determining the type of target storage medium may be accomplished in any of the three phases described above, i.e., by any of an initialization boot program, a first phase boot loader, and a second phase boot loader. After determining the type of the target storage medium, the three programs can store the type of the target storage medium in a designated register of the SOC chip of the device, so that the subsequent use is facilitated, and of course, the type of the target storage medium can also be stored in a memory of the SOC chip of the device, and can be specifically set based on actual requirements.
For example, it is assumed that in the stage of executing the initializing boot program, i.e., determining the type of the target storage medium, the type of the target storage medium may be stored in a specified register, so that the first stage boot loader may subsequently directly read the type of the target storage medium from the specified register and initialize the target storage medium using the initialization parameters adapted to the type. Similarly, the second stage boot loader may directly read the type of the target storage medium from the specified register, and obtain the initialization parameters adapted to the type to perform board level initialization, and obtain the files related to the operating system start, such as the device tree file adapted to the type, the operating system kernel, and so on, so as to start the operating system.
Of course, in some scenarios, as shown in fig. 5a, the type of the target storage medium may also be determined by the first stage bootloader based on the GPIO level difference, and then the initialization parameters matching the type may be acquired to perform the initialization process on the target storage medium, and the type of the target storage medium may be stored in the designated register. The second stage boot loader may directly read the type of the target storage medium from the specified register, obtain the board level initialization parameter matching the type, and the target file related to the operating system boot, perform board level initialization processing based on the initialization parameter, and boot the operating system based on the target file.
Of course, in some scenarios, the first stage boot loader and the second stage boot loader may each determine the type of the target storage medium by reading the level difference of the GPIO interface by themselves when the type of the target storage medium is needed.
Taking a boot loader as a uboot as an example, uboot generally includes a first-stage boot loader spl. Bin, and a second-stage boot loader uboot. Bin, and it is assumed that storage media compatible with uboot are three types, namely EMMC, norflash, and Nand Flash. The initialization parameters, the device tree files, the operating system kernel and the like corresponding to different types of storage media are considered to be different, so that the boot loader needs to determine the type of the storage media when the device operating system is booted. The GPIO interface may be configured in the SOC chip of the device, and different GPIO levels may be configured for the three storage media, respectively. When the device is started, a pre-cured initialization program in SRAM on the SOC chip of the device may determine the type of storage medium currently used based on the GPIO level. For example, the currently used storage medium is EMMC, norflash, or Nand Flash, then the type of the storage medium is stored in a designated register of the SOC chip, and the spl.bin can be loaded from the currently used storage medium to the SRAM of the SOC chip for operation, and during the operation of the spl.bin, the spl.bin can read the stored storage medium type from the designated memory, and of course, if the initialization program does not store the type of the storage medium in the designated register, the spl.bin can also read the level of GPIO by itself, determine the type of the storage medium based on the GPIO level, acquire the adapted initialization parameters based on the type of the storage medium, initialize the storage medium, then load the uboot.bin from the storage medium into the DDR of the device, and then operate the uboot.bin. For example, if the currently used storage medium is EMMC, the initialization parameters adapted to the EMMC are acquired and the EMMC is initialized. As shown in fig. 5b, after the spl. Bin loads the uboot. Bin into the DDR of the device, in the process of running the uboot. Bin, the uboot. Bin may initialize some parameters such as a clock and a memory of the device first, then initialize some shared board-level hardware parameters (i.e., the board-level hardware parameters may be classified into two types, one type is shared board-level hardware initialization parameters, i.e., for different types of storage media, the board-level hardware initialization parameters are consistent, one type is differentiated board-level hardware parameters, i.e., for different types of storage media, the board-level hardware initialization parameters are inconsistent, then the uboot. Bin may acquire the type of the storage media from a specified register (for example, after being determined by an initialization program or a first-stage boot loader, the storage media is stored in a specified memory), or may also read a GPIO level, determine the type of the storage media based on the GPIO level, then acquire different board-level hardware initialization parameters adapted to the type of the storage media, a device tree file, an operating system, and a kernel file, which is adapted to the operating system, and an operating system is started based on the different type of the initialization parameters. For example, if the currently used storage medium is EMMC, the differentiated board level hardware initialization parameters, the device tree file, the operating system kernel, etc. adapted to EMMC are acquired, board level initialization is completed based on these differentiated board level hardware initialization parameters, and starting of the operating system is completed based on these files. If the currently used storage medium is Nor Flash, different board-level hardware initialization parameters, device tree files, operating system kernels and the like which are matched with the Nor Flash are obtained, board-level initialization is completed based on the initialization parameters, and starting of an operating system is completed based on the files. If the currently used storage medium is Nand Flash, different board-level hardware initialization parameters, device tree files, operating system kernels and the like which are matched with the Nand Flash are obtained, board-level initialization is completed based on the initialization parameters, and starting of an operating system is completed based on the files.
In some embodiments, the boot loader is a binary file executable by the device obtained by compiling, so that in order to make the boot loader compatible with multiple types of storage media, when compiling the boot loader, a user may pre-configure compiling parameters meeting requirements through a configuration interface, and then compile source code of the boot loader based on the compiling parameters to obtain the boot loader. For example, the compiling parameters include at least a storage address offset of the second stage boot loader, a type of storage medium to which the boot loader is compatible, and an upper limit value of a file size that the first stage boot loader can load from the target storage medium. The source code of the bootloader may then be compiled based on the user-configured compilation parameters to obtain a binary file for the bootloader.
In order to realize that the boot loader can be compatible with various types of storage media, the storage address offset is included in the binary file obtained by compiling, wherein the storage address offset is a common multiple of the sizes of the minimum erasable units of various storage media compatible with the boot loader. The binary file obtained by compiling also comprises respective drivers of storage media compatible with the boot loader, so that various storage media can be applicable. The binary file obtained by compiling further comprises the upper limit value, and the upper limit value is larger than the size of the second stage boot loader, so that the first stage boot loader can successfully load the second stage boot loader from the target storage medium.
The solutions of the foregoing embodiments may be freely combined to obtain a new solution without any conflict, for reasons of space, which are not exemplified herein.
In addition, the embodiment of the application further provides a device based on a boot loader, where the boot loader includes a first stage boot loader and a second stage boot loader, as shown in fig. 6, and the device 60 includes:
a loading module 61, configured to load the first stage boot loader from a target storage medium storing the boot loader after detecting that the device is powered on, execute the first stage boot loader to obtain a storage address offset of the second stage boot loader, and load the second stage boot loader from the target storage medium based on the storage address offset;
an execution module 62 for executing the second stage boot loader to boot an operating system of the device;
wherein the storage address offset is an offset of a starting storage address of the second stage boot loader in the target storage medium relative to a starting storage address of the first stage boot loader in the target storage medium; the storage address offset is a common multiple of the sizes of respective minimum erasable units of at least two storage media compatible with the bootloader.
The specific process of the device implementing device start-up may refer to the description in the method, and embodiments of the present application are not limited.
In addition, as shown in fig. 7, the embodiment of the present application further provides an electronic device, where the electronic device includes a processor 71 and a memory 72, where the memory 72 stores a computer program, and when the computer program is executed by the processor 71, the method mentioned in any of the foregoing embodiments may be implemented.
Furthermore, embodiments of the present application provide a computer program product comprising a computer program which, when executed by a processor, implements the method mentioned in any of the above embodiments.
Accordingly, the embodiments of the present application also provide a computer storage medium having a program stored therein, which when executed by a processor, implements the method in any of the embodiments described above.
Embodiments of the present application may take the form of a computer program product embodied on one or more storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having program code embodied therein. Computer-usable storage media include both permanent and non-permanent, removable and non-removable media, and information storage may be implemented by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to: phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, may be used to store information that may be accessed by the computing device.
For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.
User information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, presented data, etc.) referred to herein are both user-authorized or fully authorized information and data by parties, and the collection, use and processing of relevant data requires compliance with relevant laws and regulations and standards of the relevant country and region, and is provided with corresponding operation portals for user selection of authorization or denial.
It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing has outlined rather broadly the methods and apparatus provided in embodiments of the present invention in order that the detailed description of the principles and embodiments of the present invention may be implemented in any way that is used to facilitate the understanding of the method and core concepts of the present invention; meanwhile, as those skilled in the art will have variations in the specific embodiments and application scope in accordance with the ideas of the present invention, the present description should not be construed as limiting the present invention in view of the above.
Claims (11)
1. A method of booting a device based on a bootloader, the bootloader comprising a first stage bootloader and a second stage bootloader, the method comprising:
after detecting that the device is powered on, loading the first-stage boot loader from a target storage medium storing the boot loader, executing the first-stage boot loader to acquire a storage address offset of the second-stage boot loader, and loading the second-stage boot loader from the target storage medium based on the storage address offset;
executing the second stage boot loader to boot an operating system of the device;
wherein the storage address offset is an offset of a starting storage address of the second stage boot loader in the target storage medium relative to a starting storage address of the first stage boot loader in the target storage medium; the storage address offset is a common multiple of the sizes of respective minimum erasable units of at least two storage media compatible with the bootloader.
2. The method of claim 1, wherein the storage address offset is a least common multiple of the sizes of respective least erasable units of at least two storage media compatible with the bootloader.
3. The method of claim 1, wherein the executing the first stage bootloader prior to obtaining a storage address offset for the second stage bootloader and loading the second stage bootloader from the target storage medium based on the storage address offset is further configured to:
acquiring the type of the target storage medium, acquiring initialization parameters matched with the type from the target storage medium, and initializing the target storage medium based on the initialization parameters;
after the initialization operation on the target storage medium is completed, the operation of acquiring the storage address offset of the second-stage boot loader and loading the second-stage boot loader from the target storage medium based on the storage address offset is executed.
4. The method of claim 1, wherein executing the second stage boot loader to boot an operating system of the device comprises:
and executing the second stage boot loader to acquire the type of the target storage medium, loading a target file matched with the type from the target storage medium, and starting the operating system based on the target file, wherein the target file is a file related to starting of the operating system.
5. The method of claim 4, wherein the target file comprises one or more of:
device tree files, operating system kernel, file system.
6. The method according to claim 3 or 4, wherein the device comprises an SOC chip, the type of the target storage medium is determinable by executing any one of an initialization boot program, the first stage boot loader, the second stage boot loader, and storing the determined type of the target storage medium in a designated register of the device, wherein the initialization boot program is cured in the SOC chip of the device for loading the first stage boot loader from the target storage medium.
7. A method according to claim 3 or 4, wherein the device comprises a SOC chip in which a GPIO interface is configured, the level signals of the GPIO interface being different for at least two storage mediums compatible with the boot loader, the type of the target storage medium being determinable by reading the level signals of the GPIO interface.
8. The method of claim 1, wherein the bootloader is a compiled binary file, the binary file being compiled by:
Acquiring compiling parameters configured by a user, wherein the compiling parameters comprise the storage address offset, the type of a storage medium compatible with the boot loader and the upper limit value of the file size which can be loaded from the target storage medium by the first-stage boot loader; wherein the upper limit is greater than the second stage boot loader size;
compiling source codes of the boot loader based on the compiling parameters to obtain the binary file; the binary file includes a driver of a storage medium compatible with the boot loader, the storage address offset, and the upper limit value.
9. An apparatus for booting a device based on a bootloader, the bootloader comprising a first stage bootloader and a second stage bootloader, the apparatus comprising:
the loading module is used for loading the first-stage boot loader from a target storage medium storing the boot loader after the device is detected to be powered on, executing the first-stage boot loader to acquire the storage address offset of the second-stage boot loader, and loading the second-stage boot loader from the target storage medium based on the storage address offset;
The execution module is used for executing the second-stage boot loader to start an operating system of the equipment;
wherein the storage address offset is an offset of a starting storage address of the second stage boot loader in the target storage medium relative to a starting storage address of the first stage boot loader in the target storage medium; the storage address offset is a common multiple of the sizes of respective minimum erasable units of at least two storage media compatible with the bootloader.
10. An electronic device comprising a processor, a memory, and a computer program stored in the memory for execution by the processor, the computer program when executed implementing the method of any one of claims 1-8.
11. A computer program product comprising a computer program which, when executed by a processor, implements the method of any of claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410263773.2A CN117850895B (en) | 2024-03-07 | 2024-03-07 | Method and device for starting equipment based on boot loader and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410263773.2A CN117850895B (en) | 2024-03-07 | 2024-03-07 | Method and device for starting equipment based on boot loader and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117850895A true CN117850895A (en) | 2024-04-09 |
| CN117850895B CN117850895B (en) | 2024-05-07 |
Family
ID=90529005
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410263773.2A Active CN117850895B (en) | 2024-03-07 | 2024-03-07 | Method and device for starting equipment based on boot loader and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117850895B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080320294A1 (en) * | 2007-06-20 | 2008-12-25 | International Business Machines Corporation | User selectable configuration options application for inaccessible nonvolatile storage at bootstrap |
| CN110399173A (en) * | 2019-07-26 | 2019-11-01 | 苏州浪潮智能科技有限公司 | A kind of system and its system start method based on RISC-V processor |
| CN113821265A (en) * | 2021-11-22 | 2021-12-21 | 深圳华北工控软件技术有限公司 | Operating system control method and device, computer mainboard and readable storage medium |
| CN113961259A (en) * | 2021-11-01 | 2022-01-21 | 锐凌无线通讯科技(深圳)有限公司 | Boot program loading starting method, device, system, electronic equipment and medium |
-
2024
- 2024-03-07 CN CN202410263773.2A patent/CN117850895B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080320294A1 (en) * | 2007-06-20 | 2008-12-25 | International Business Machines Corporation | User selectable configuration options application for inaccessible nonvolatile storage at bootstrap |
| CN110399173A (en) * | 2019-07-26 | 2019-11-01 | 苏州浪潮智能科技有限公司 | A kind of system and its system start method based on RISC-V processor |
| CN113961259A (en) * | 2021-11-01 | 2022-01-21 | 锐凌无线通讯科技(深圳)有限公司 | Boot program loading starting method, device, system, electronic equipment and medium |
| CN113821265A (en) * | 2021-11-22 | 2021-12-21 | 深圳华北工控软件技术有限公司 | Operating system control method and device, computer mainboard and readable storage medium |
Non-Patent Citations (2)
| Title |
|---|
| RENE KORTHAUS 等: "A practical property-based bootstrap architecture", 《STC\'09：PROCEEDINGS OF THE 2009 ACM WORKSHOP ON SCALABLE TRUSTED COMPUTING》, 13 November 2009 (2009-11-13) * |
| 苗施亮: "硬盘固件病毒检测系统的设计与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑 (月刊)》, 15 April 2018 (2018-04-15) * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117850895B (en) | 2024-05-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6633976B1 (en) | Method of storing BIOS modules and transferring them to memory for execution | |
| US5918047A (en) | Initializing a processing system | |
| US7725700B2 (en) | Embedded system, automatic loading system, and method capable of automatically loading a root file system | |
| US11042383B2 (en) | System and method for boot speed optimization using non-volatile dual in-line memory modules | |
| CN106708587B (en) | Parameter configuration method and system | |
| US20060224874A1 (en) | Method for updating system management basic input output system (SMBIOS) data | |
| CN108829449B (en) | Method, device, equipment and medium for starting operating system by BIOS (basic input output System) | |
| US10866881B1 (en) | Firmware debug trace capture | |
| US20180059978A1 (en) | Virtual disk expansion method and apparatus | |
| CN103135947B (en) | A kind of method and apparatus showing Windows drive | |
| US7219221B2 (en) | System and method for automatic booting based on single flash ROM | |
| US7003656B2 (en) | Automatic selection of firmware for a computer that allows a plurality of process types | |
| CN114116505A (en) | Code testing method and device | |
| CN117850895B (en) | Method and device for starting equipment based on boot loader and electronic equipment | |
| CN116700629B (en) | Data processing method and device | |
| CN111694580B (en) | Method and device for upgrading and initializing storage device and electronic device | |
| CN115630025B (en) | System and method for monitoring file changes in a shared file system | |
| CN111930575A (en) | Firmware acquisition method and device and electronic equipment | |
| TW201715384A (en) | Setting a build indicator to enable or disable a feature | |
| CN113407187A (en) | Method, device and equipment for constructing file system and computer storage medium | |
| US20050060530A1 (en) | Method for displaying information of updating BIOS | |
| TWI493463B (en) | Electronic device, universal extension firmware interface Basic input and output system firmware update method, recording media and computer program products | |
| US8359456B2 (en) | Generating random addresses for verification of distributed computerized devices | |
| CN111309526A (en) | File backup and recovery method and device | |
| CN106897588B (en) | Processing method and device of label function |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |