A method, apparatus, and storage medium for booting a versatile configurable embedded system

Abstract

This invention discloses a diversified and configurable embedded system bootloader method, supporting both multi-functional and fast-start modes. The multi-functional mode includes four operating stages: (1) performing the first relocation and establishing a high-level language runtime environment, running the hardware debugging user interface in a context without system memory; (2) performing system memory initialization and a second relocation, moving the runtime environment to system memory; (3) starting the mini operating system kernel, supporting various advanced features during the startup stage; and (4) loading and starting the target operating system. In the fast-start mode, real-time applications are directly loaded after hardware initialization. This invention solves the defects of traditional bootloader operation, providing an independent debugging stage that does not depend on memory to complete hardware diagnosis and testing. It meets the application needs of different scenarios through dynamic configuration, and has broad application prospects. In addition, this invention also discloses a system bootloader device and storage medium.

Description

Technical Field

[0001] This invention relates to the fields of computer low-level operation and embedded system technology, and in particular to a diverse configurable embedded system boot loading method, apparatus and storage medium. Background Technology

[0002] The bootloader is a crucial component for the startup and operation of an embedded system. During system startup, the bootloader is responsible for initializing hardware devices, such as the processor, memory, and peripherals, ensuring the system is in a normal working state. Furthermore, it needs to read the operating system image from storage devices, load it into memory, and start the target operating system.

[0003] Secondly, a highly efficient and configurable bootloader provides flexible operating system options. In some cases, embedded systems may need to support multiple operating systems or different boot modes. By providing boot options, the bootloader allows users to select different operating systems or boot modes as needed, thereby meeting diverse application requirements.

[0004] Furthermore, the bootloader also features a firmware upgrade mechanism, which is crucial for the maintenance and upgrades of embedded systems. Through the bootloader, the system can easily update and upgrade its firmware to support new features, fix vulnerabilities, or improve system performance. This mechanism ensures the continuous evolution and adaptability of embedded systems.

[0005] Furthermore, the bootloader plays a crucial role in the integrity checks of embedded systems. It manages the system image and checks and ensures the security of software updates. This is essential for preventing malware attacks and maintaining system stability.

[0006] Finally, an efficient and configurable bootloader helps reduce the development and maintenance costs of embedded systems. By optimizing the system startup and runtime process, it reduces resource consumption and failure rates, improving system reliability and stability. At the same time, flexible configuration options allow developers to more easily customize and optimize the system to meet specific application requirements.

[0007] Embedded system bootloaders traditionally consist of two stages: a low-level language stage and a high-level language stage. The low-level language stage is typically written in assembly language. This stage primarily utilizes the instruction affinity of assembly language to perform low-level hardware initialization tasks, the most important of which is initializing system memory and establishing the stack pointer to expedite the transition to the high-level language stage. The second stage is usually implemented using a high-level language. The bootloader in this stage can use advanced data structures and algorithms to drive more complex tasks. This stage is mainly responsible for further complete hardware initialization, system environment configuration, device driver loading, and operating system loading and startup.

[0008] Embedded systems, due to space constraints, often face challenges such as wiring complexity and signal interference. Wiring complexity primarily stems from the large number of signal transmission lines within embedded systems. These lines are not only numerous but also densely packed, making them susceptible to interference from external electromagnetic fields and other factors. Signal interference can originate from other internal components, such as high-frequency circuits or power supplies, or from external environmental sources like lightning and radio waves. The combined effect of all these factors means that the actual access timing required by the on-board memory may not perfectly match the ideal timing from simulation results, typically requiring further adjustments. Furthermore, hardware developers need a test-oriented tool (DFT, design for test) to stress-test the entire memory access space and basic external interfaces. Ideally, this test should be completely independent of the object under test, especially the memory itself. Given that memory configuration, particularly timing configuration, is typically completed at the assembly language stage in traditional systems, the inherent coupling characteristics of assembly language to the processor architecture and the complexity of its instruction set prevent the provision of a portable, programmable interface at this stage for complex hardware debugging functions such as timing adjustments and stress testing.

[0009] Traditional embedded bootloaders have relatively simple functions, mainly focusing on hardware initialization and booting the operating system or applications. However, with technological advancements and the increasing complexity of embedded systems, supporting more advanced functions and features has become urgent. Due to existing differences, directly porting functionality from the operating system to the bootloader typically requires extensive modifications and refactoring, including redesigning the program structure, adjusting the programming interface, optimizing resource usage, and enhancing security. If the required functionality is too complex or relies on specific services provided by the operating system, it cannot be directly ported to the bootloader.

[0010] Furthermore, the slow startup speed of traditional embedded systems leads to a series of problems, including poor user experience, low system efficiency, limited application scenarios, and difficulties in maintenance and upgrades. In many embedded applications, especially those with extremely high real-time requirements (such as industrial automation, medical devices, and aerospace), rapid system startup and response speed are crucial. Slow startup speed means a long delay between device power-on and the ability to execute critical tasks, which can affect the real-time performance of the entire system. Summary of the Invention

[0011] In view of this, one of the objectives of this invention is to provide an embedded system bootloader method for hardware debugging, which solves the problems of traditional bootloaders lacking hardware debugging means and relying on system memory for operation.

[0012] One of the objectives of this invention is achieved through the following technical solution:

[0013] This diverse and configurable embedded system boot loading method includes the following steps:

[0014] Phase 1: Initialize the hardware and set up the environment. Use the microprocessor cache to perform the first relocation and establish the runtime environment for the high-level language to support the running of the hardware debugging user interface in a context where system memory is unavailable.

[0015] The second stage involves performing hardware debugging and saving the debugged parameters to the flash memory parameter area, initializing the system memory and performing a second relocation, and moving the overall operating environment to the main memory.

[0016] The third stage: In multi-functional mode, the mini operating system kernel is started and used as part of the bootloader of this invention to support various complex advanced features during the boot phase; in fast boot mode, this step will be skipped directly.

[0017] Phase 4: Loading and starting the target operating system; Unlike the normal loading process of the target system in multi-functional mode, the fast startup mode will perform a special optimized process and load the embedded real-time application in the shortest possible time.

[0018] Furthermore, in the first stage, the processor's data cache is locked and mapped to a processor-accessible memory address to provide a basic environment for high-level language programs to run, independent of the main memory; relocation technology is used to move the data segments required for the execution of the first stage code from flash memory to the corresponding locations in the data cache, locate the address of the uninitialized data segment bss in the data cache and perform a zeroing operation, and finally establish a stack pointer at the top of the data cache.

[0019] Furthermore, the first phase specifically includes the following steps:

[0020] Step S11: Start the embedded system, and the microprocessor begins loading the reset vector stored at a predetermined address on the directly executable flash memory;

[0021] Step S12: Load the first-stage initialization program to complete the initialization of the processor's on-chip cache; the on-chip cache includes instruction cache and data cache;

[0022] Step S13: Configure the processor memory management control unit to linearly map the data cache to the processor's accessible space and perform a locking operation to prevent swapping in and out. After the above steps, the data cache is now equivalent to a high-speed static random access memory connected inside the processor.

[0023] Step S14: Move the data segment from flash memory to the data cache address space, perform a zeroing operation on the BSS segment of the space (i.e., the first relocation), and establish a stack pointer at the top of the data cache; jump the program pointer to the second stage address in flash memory and execute the code of the second stage.

[0024] Furthermore, the specific steps of the second phase include:

[0025] In the second stage, the following specific steps are performed:

[0026] Step S21: Build a hardware debugging user interface based on the cache that does not depend on the system's main memory;

[0027] Step S22: Initialize the system memory using the memory parameters obtained during debugging;

[0028] Step S23: Move the data segment and BSS segment from the cache and flash memory to the system memory respectively, and re-establish the stack pointer at the highest memory address, i.e., the second relocation;

[0029] Step S24: Move the code segment from flash memory to system memory;

[0030] Step S25: Release the lock and address space mapping for the data cache.

[0031] Furthermore, it is necessary to first determine the memory layout and data transfer rules for the bootloader at each stage based on the processor's address access space specifications.

[0032] Furthermore, in the second stage, a locking operation will be performed on the data cache and the processor will be prohibited from triggering a page fault when the data access in the cache is missing, as well as subsequent data exchange operations with the system memory. This process depends on the operation interface provided by the processor.

[0033] Furthermore, before the first stage, it is necessary to formulate the memory layout and data transfer rules for the bootloader at each stage based on the processor's address access specifications.

[0034] Furthermore, in the second stage, a locking operation is performed on the data cache to prevent the processor from triggering a page fault when the cache access data is missing, as well as from data exchange operations with system memory.

[0035] Furthermore, the mini version is a streamlined version of a full operating system, including a minimized kernel and root file system, in order to meet the minimum boot time requirement while supporting various advanced features.

[0036] A second objective of this invention is to provide a diverse and configurable embedded system bootloader, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the computer program to implement the method described above.

[0037] A third objective of this invention is to provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0038] This invention provides a flexible boot loading method. After the second stage is completed, it will determine whether it is in a multi-functional boot mode or a fast boot mode according to the preset boot mode. This can meet the multi-functional requirements of modern embedded systems for boot loaders, as well as the fast boot requirements of traditional embedded real-time systems and specific application scenarios.

[0039] If the current boot mode is multi-functional, it will jump to a streamlined mini-operating system. This operating system will serve as an independent stage of this bootloader, providing a range of advanced features not available in traditional bootloaders. Traditional bootloaders, due to code size limitations, lag significantly behind true operating systems in terms of both supported new hardware devices and software functionalities such as communication and network protocols. Therefore, this invention introduces a mini-operating system as part of the bootloader. The mini-operating system described in this invention includes a streamlined operating system kernel and a streamlined root file system.

[0040] If the current boot mode is fast, the target operating system kernel will be loaded directly using optimized boot methods. In this mode, the kernel will be loaded immediately after the CPU subsystem (PLL, DDR) initialization is completed in the second stage. At the same time, the bootloader will set the kernel to fast boot mode by passing parameters. The operating system kernel booted in this mode will perform a series of boot optimization actions, such as disabling command line output printing, loading a minimal set of drivers and system services, skipping time-intensive actions such as Loops_per_jeffy calibration by preset values, and disabling kernel IP auto-configuration, thereby ensuring that the embedded real-time application is loaded with minimal time cost and that it can respond to real-time events as quickly as possible.

[0041] The beneficial effects of this invention are:

[0042] The method of this invention solves the defect that traditional embedded system bootloaders run entirely based on the system's main memory. Based on data caching, it provides a debugging stage and debugging interface independent of the system's main memory, which can complete the diagnosis and testing of the main memory and other on-chip / board devices. This invention innovatively introduces a mini-system into the boot loading stage, providing rich functionality that traditional systems do not have in the early stages of system startup. This invention can meet the different needs of both modern non-real-time systems and traditional real-time systems in terms of bootloaders through configuration, and has a wide range of applications and good application prospects.

[0043] Other advantages, objectives, and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination, or may be learned from practice of the invention. The objectives and other advantages of the invention can be realized and obtained from the following description and the foregoing claims. Attached Figure Description

[0044] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will now be described in further detail with reference to the accompanying drawings, wherein:

[0045] Figure 1 This is a flowchart of the first stage of an embodiment of the present invention.

[0046] Figure 2 This is a flowchart of the second stage of an embodiment of the present invention.

[0047] Figure 3 This is a flowchart of the fourth stage of an embodiment of the present invention.

[0048] Figure 4 This is a flowchart illustrating the quick startup process of an embodiment of the present invention.

[0049] Figure 5 This is a schematic diagram of the system composition according to an embodiment of the present invention. Detailed Implementation

[0050] The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be understood that the preferred embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0051] The hardware system of this invention consists of an embedded microprocessor (CPU), a flash memory chip (supporting on-chip execution, eXecute-In-Place, abbreviated as XIP), and a memory chip (usually dynamic random access memory SDRAM, or double data rate memory DDR).

[0052] Embedded microprocessors are the core components of embedded systems. They integrate CPU, memory, and input / output interfaces and are widely used in various embedded systems. Compared with general-purpose processors, they have advantages such as low power consumption, low cost, customization, and high integration.

[0053] Flash memory chips and on-chip execution: Flash memory chips store the boot code, operating system, applications, and other critical data for embedded systems. XIP technology allows the CPU to execute code directly from the flash memory chip without copying it into system memory, thus improving system boot speed. Boot loaders can use XIP functionality to execute some or all of the boot code directly from flash memory.

[0054] Memory chips: Used to store runtime data and programs. Because flash memory chips have relatively slow read speeds, loading data and programs into system memory can significantly improve system performance. The bootloader initializes system memory and sets its operating parameters (such as clock frequency, latency, etc.) during startup. This chip is also the primary working memory for the operating system and applications.

[0055] The code involved in this invention is all Position Independent Code (PIC). PIC code is a type of machine code that allows code to run correctly from any location in main memory, regardless of its absolute address. This characteristic is particularly crucial for supporting the multiple relocations involved in the execution of this invention. PIC relies on the following mechanisms for implementation:

[0056] 1. Global Offset Table (GOT): In the PIC implementation, the compiler creates a GOT at the beginning of each data segment, containing the address of every global object referenced by the target module. During runtime, the program indirectly references and modifies global variables through the GOT, thus ensuring that relocated data can be loaded and referenced correctly by the program.

[0057] 2. Procedure Link Table (PLT): PIC uses the Procedure Link Table to implement lazy binding. When a program calls an external function for the first time, it interacts with the dynamic linker through the PLT and GOT to obtain the function's actual address and stores it in the GOT. Subsequent calls can then be made directly through the address in the GOT, thus ensuring that this invention can call relocated functions and interfaces from any address.

[0058] Because the bootloader has different address space layouts at different execution stages, precise control over the program's memory layout at these stages is crucial. This is accomplished through the linker script, which includes:

[0059] 1. Describe memory layout: Describe how segments in the input file (such as code segment, data segment, BSS segment, stack segment, extra segment, etc.) are mapped to the output file, and the layout of the output file in system memory;

[0060] 2. Define symbol addresses: Define a symbol table. These symbols play an important role in the startup and execution of the program, such as the program's entry point (_start) and the starting address of the data segment (_data_start).

[0061] In this invention, the memory layout undergoes two changes during program execution (a first relocation and a second relocation). Relocation refers to the process of moving code from one memory address to another; during relocation, symbolic references in the code need to be corrected to ensure they point to the correct memory addresses. As mentioned earlier, symbolic correction must be performed based on position-independent code (PIC).

[0062] The relationship between relocation and linker scripts is as follows:

[0063] 1. Memory Layout and Relocation Target: The memory layout defined by the linker script provides the target address for relocation. The linker script determines where each segment of the bootloader should be loaded into the address space, as well as the starting address and size of each segment;

[0064] 2. Symbol Addresses and Relocation Correction: The symbol addresses defined in the linker script are the basis for relocation correction. During the relocation process, the bootloader refers to the symbol addresses defined in the linker script to correct symbol references in the code, ensuring they point to the correct memory addresses;

[0065] 3. Dependencies: The relocation process depends on the linker script. Without a correctly defined linker script, the bootloader cannot complete the relocation process correctly, causing the program to malfunction.

[0066] The workflow of the present invention will be fully described below with reference to the accompanying drawings.

[0067] This invention balances the diverse functional requirements of modern non-real-time systems with the stringent time constraints of traditional real-time systems for real-time application startup. It supports configuring the bootloader in two different modes: multi-functional and fast startup, to address various usage scenarios. The startup mode configuration is stored in flash memory.

[0068] This invention includes four stages in a multi-functional mode:

[0069] Phase 1: This phase is written in a low-level language (usually assembly language) and mainly involves hardware initialization and environment setup to ensure the system can smoothly transition to Phase 2 and load the hardware debugging user interface. For example... Figure 1 As shown, the process includes locking the processor's data cache and mapping it to a processor-accessible memory address to provide a basic environment for high-level language programs to run, independent of main memory; using relocation technology to move the data segments required for the first stage of code execution from flash memory to the corresponding locations in the data cache; locating the address of the uninitialized data segment bss in the data cache and performing a zeroing operation; establishing a stack pointer at the top of the data cache; and finally loading the hardware debugging user interface.

[0070] The first phase specifically includes the following steps:

[0071] Step S11: Power on the embedded system and begin loading the predetermined reset vector stored in the directly executable flash memory;

[0072] In this embodiment, the startup entry point is defined in the linker script ENTRY(_start), where _start is the starting point for the bootloader startup.

[0073] Boot Mode: After the processor powers on, it loads the first-stage assembly code from the pre-defined boot medium (flash memory in this invention) at a predetermined address according to the preset boot mode. This code sets the processor to Supervisor mode. This mode is mainly used for programs that require privileged operations from the underlying loader and operating system. These programs can freely access protected registers and perform privileged operations, thereby achieving fine-grained management of the system.

[0074] Step S12: Initialize the processor's on-chip cache, which includes an instruction cache and a data cache. Initializing the data cache primarily involves locking it to disable swapping in and out between the data cache and main memory. This operation typically requires programming the processor's control registers. These registers contain bit fields that control cache behavior, memory management, and other processor features. Specifically, this involves setting specific bit fields to disable write-back or pass-through modes for the data cache.

[0075] Step S13: Configure the processor's Memory Management Unit (MMU) to linearly map the data cache to the processor's accessible space. The MMU is a crucial component of the processor, responsible for translating virtual addresses into physical addresses so the processor can access data in memory. The MMU uses page tables to implement this mapping, a data structure stored in memory that records the mapping relationship between virtual and physical addresses. The first-stage code of this invention sets the corresponding virtual address range for the physical address range of the data cache in the page table. When the processor attempts to access these virtual addresses, the MMU translates them into the corresponding physical address of the data cache.

[0076] After the above steps, the data cache is locked by the processor and cannot be automatically swapped in and out of system memory. It is also mapped to an independent address space accessible to the processor. Accessing this address will directly hit the processor's data cache, which is equivalent to having an additional static memory that can be accessed directly through the address space just like system memory.

[0077] Step S14: Perform the first relocation. As mentioned earlier, the linker script has determined the locations of the data segment and BSS segment in the static memory simulated using the data cache. At this point, it is only necessary to copy the data segment to the corresponding location in the cache, zero out the BSS segment, and establish a stack pointer at a reasonable location (usually the top of the data cache) to complete the first relocation.

[0078] Second stage: In this embodiment, the code for the second stage is entirely written in a high-level language.

[0079] Main functions of this stage:

[0080] 1. Provides a powerful command-line tool that offers diagnostic functions for the system's hardware and basic peripherals;

[0081] 2. This stage of operation is completely independent of system memory, so it is possible to perform system memory initialization configuration, test access timing, and perform full-area scan and stress testing on the entire memory.

[0082] 3. Supports writing the tested memory access configuration to the configuration parameter area defined in flash memory.

[0083] like Figure 2As shown, the second stage includes: building a hardware debugging user interface written in a high-level language that is independent of the system's main memory. Based on this user interface, the system's main memory can be initialized and its timing configured, and a full-range scan and stress test can be performed on the entire system's main memory space. A second relocation operation is then performed based on the system memory that has already undergone initialization and stability testing. This involves copying the data segment and BSS segment contents from the data cache to system memory, re-establishing the stack pointer in system memory, and finally moving the mini-operating system's kernel and root file system to system memory and jumping to the starting address of the mini-kernel in the third stage.

[0084] The specific steps for the second phase are as follows:

[0085] Step S21: Initialize system memory:

[0086] 1. Write the memory parameters (including memory timings and chip configuration) stored in the flash memory parameter area to the memory controller;

[0087] 2. Initialize other memory access-related registers and control logic.

[0088] Step S22: According to the linker script, the data segment, BSS segment, and code segment are moved from the cache and flash memory to the system memory space that has been tested and verified, respectively. The stack pointer is re-established at the highest memory address (second relocation); the layout after the second relocation is still defined by the linker script.

[0089] 1. Locate the addresses of the data segment and BSS segment in the data cache and their relocated addresses in system memory; copy the data segment and BSS segment from the data cache to the specified addresses in system memory respectively;

[0090] 2. Reset the stack pointer in system memory;

[0091] Step S23: Release the lock on the data cache and remove the address space mapping for the data cache from the MMU. At this point, the data cache resumes its normal function and is no longer used as on-chip static memory;

[0092] Step S24: Obtain the current boot configuration and determine whether this boot is in multi-function boot mode or fast boot mode. In multi-function boot mode, execution will jump to the starting address of the mini kernel and begin the third stage; in fast boot mode, the target operating system kernel will be loaded directly in the context of the second stage. The execution steps for fast boot mode will be explained in detail in later chapters.

[0093] Step S25: In multi-function mode, the trimmed mini operating system is copied from flash memory to system memory and a jump is performed. The specific steps are as follows:

[0094] 1. Copy the mini kernel to a predefined kernel region in system memory;

[0095] 2. Copy the mini root file system to a predefined file system region in system memory;

[0096] 3. Write the mini root file system address to the specified register or the specified address (so that the mini kernel can obtain the file system address);

[0097] 4. Jump to the starting address of the mini kernel and begin loading the mini operating system.

[0098] Phase Three: Phase Three will jump to a streamlined mini-operating system, which will serve as a separate phase of this bootloader, providing a range of advanced features not available in traditional bootloaders. This phase will be skipped in fast boot mode.

[0099] Traditional bootloaders, due to limitations in code size, lag significantly behind true operating systems in terms of both supported new hardware and software functionalities such as communication and network protocols. This invention introduces a mini-operating system as part of the bootloader. This mini-operating system includes a streamlined operating system kernel and a streamlined root file system.

[0100] In this embodiment, the simplified operating system kernel includes the following parts:

[0101] 1. Core Functions: Includes the most basic system management and scheduling functions, but compared to a complete operating system kernel, it significantly reduces unnecessary modules and services to reduce size and memory usage;

[0102] 2. Hardware Abstraction Layer: Supports the latest storage devices, network devices, and input / output devices. This enables the invention to run on multiple hardware platforms, ensuring versatility and compatibility.

[0103] 3. Security Features: Includes basic security features such as boot verification, secure boot, and early malware detection.

[0104] A streamlined root file system includes the following components:

[0105] 1. Basic Toolset: Includes essential tools and configuration files for the startup process, such as file system mounting tools, network configuration tools, and logging tools. These tools enable the invention to perform more complex tasks, such as network booting and remote configuration.

[0106] 2. Modular Design: To maintain the simplicity of the root file system, this invention adopts a modular design. Only necessary modules and files are included in the root file system, while other non-essential functions can be implemented through dynamic loading.

[0107] 3. Fast startup: Since the main task of the bootloader is to get the system into a usable state in the shortest possible time, the root file system should be designed to be as efficient as possible to reduce startup time.

[0108] With the help of a mini operating system, this invention will provide a variety of advanced features during the startup phase, including but not limited to:

[0109] 1. File system support: This mini operating system supports file system operations, allowing users to access and modify files on the storage medium during the boot process;

[0110] 2. Network Support: This mini system includes a complete network driver and protocol stack, enabling it to work in a network environment and achieve functions such as network boot and remote management;

[0111] 3. Graphical User Interface: This mini system provides a simple graphical user interface to allow users to make selections and configurations more intuitively;

[0112] 4. Advanced Diagnostics and Repair: This mini-system includes tools and programs for system diagnostics, repair, and recovery to help users resolve problems encountered during startup;

[0113] 5. Multi-operating system support: If multiple operating systems are installed on the system, this mini system can also provide a selection menu, allowing users to choose the target operating system to boot.

[0114] Fourth stage: Load the target operating system within the context of the mini-operating system. For example... Figure 3 As shown, the specific steps are as follows:

[0115] Step S41: Parse the target kernel image and extract the necessary header and segment information;

[0116] Step S42: Memory Allocation. Allocate physical memory pages for the target kernel and the target root file system, and link these pages together to form a reserved memory layout; write-protect these reserved areas using the mechanisms provided by the mini-kernel; copy the code and data segments from the target kernel image to the reserved memory areas.

[0117] Step S43: Record key information. This includes the entry address of the new kernel and the load address of the new root file system; this information will be used in subsequent jumps.

[0118] Step S44: Perform a jump to start the new kernel. Move the instruction pointer to the entry address of the new kernel, pass the entry address of the root file system using a specified register, and start the target operating system.

[0119] In step S42, the new kernel and the new root file system image will be loaded into memory that is stored as contiguously as possible. The address of the new root file system is recorded separately in a special variable for use in subsequent processes. Since the new kernel image has a specified entry address and this memory is being used by the current mini operating system kernel, it is necessary to temporarily allocate memory space for the new kernel image to temporarily store the image. Before jumping, its contents are moved to the specified entry address and the jump is performed. If the new root file system is large, it can be distributed and stored in available memory pages first, and then moved and spliced ​​to the destination address before jumping to the new kernel.

[0120] Compared to the multi-functional mode, this invention, in fast boot mode, prepares the target operating system's loading parameters based on the second-stage context. These parameters optimize the target operating system's initialization process to improve boot speed, ensuring a seamless transfer of system control to the embedded real-time application with minimal time overhead. These optimization parameters include settings at both the operating system and application levels.

[0121] Optimization settings at the operating system level:

[0122] 1. Disable time-consuming functions of the operating system kernel, such as automatic IP configuration;

[0123] 2. Disable console output printing during the operating system startup phase;

[0124] 3. Pre-set the loops_per_jiffy parameter. loops_per_jiffy (LPJ) is an important kernel parameter used to calculate minute time delays. During kernel startup, a delay loop calibration process is performed to calculate the accurate value of LPJ. In fast boot mode, this value is directly passed from the bootloader to the kernel, and the kernel does not need to perform the delay loop calibration process.

[0125] 4. Load the embedded real-time application at a priority location in the initialization script;

[0126] 5. Keep the root file system resident in memory to ensure the real-time access of the file system by applications;

[0127] 6. Disable kernel debug printing;

[0128] 7. Turn off system logs.

[0129] Optimization settings at the application level:

[0130] 1. Reduce application dependencies on system libraries. For real-time applications, use static linking to reduce the overhead caused by dynamic loader indexing and dynamic loading of library files.

[0131] 2. Use lightweight standard C libraries such as uClibC to reduce file size and reduce loading overhead for the target application;

[0132] 3. Optimize application building by using space-optimized compilers, hardware software decoding instructions, hardware floating-point vector units, and other acceleration methods.

[0133] In embedded real-time systems, application layer services are typically divided into real-time and non-real-time components. The real-time component mainly refers to the embedded real-time application, which is the critical process for the system to respond to external real-time events; its startup speed is a key indicator of the system's real-time performance. The non-real-time component consists of other background service processes (such as network time synchronization services), which are not time-critical and can therefore be loaded later. This invention utilizes the mini-file system embedded in the system as described in the third stage to achieve rapid loading of real-time applications and delay the startup of other non-real-time services.

[0134] The following modifications are made to the second stage in Fast Startup mode:

[0135] Step S51: Load the target operating system kernel and mini file system from the external media into the system memory using DMA.

[0136] Step S52: Prepare optimization parameters for fast kernel startup, such as LPJ value, minimize serial port printing, etc.

[0137] Step S53: Proceed to the fourth stage and begin rapidly loading the target system.

[0138] The following modifications are made to the fourth stage in Fast Startup mode:

[0139] Step S61: Pass the fast boot parameters to the target operating system kernel and specify the mini file system as its root file system.

[0140] Step S62: After the target kernel quickly completes initialization, it immediately mounts the mini file system and executes a simplified initialization script;

[0141] Step S63: Immediately start the embedded real-time application at the priority location of the mini file system initialization script and begin responding to external real-time events; at this point, the real-time component loading is complete.

[0142] The next steps complete the loading of the non-real-time portion:

[0143] Step S64: Mount the target file system to the specified directory of the mini file system;

[0144] Step S65: Switch the root file system from the mini file system to the target file system;

[0145] Step S66: Delay the execution of non-real-time services of the target file system to complete the booting of the entire system.

[0146] Based on the above design, in fast boot mode, the bootloader will optimize the default parameters of the target kernel and perform a root file system switch. For example... Figure 4 As shown, the target kernel exists as a compressed file on external media. First, the target kernel is quickly loaded into system memory from the external media using DMA, decompression is performed, boot parameters are optimized, and the root file system is specified as a mini file system. The kernel completes a fast boot based on the optimized parameters and immediately executes the initialization script of the mini file system. This initialization script directly loads the embedded real-time application, which is fixed in a predetermined location on the external media, into memory and executes it. The embedded real-time application and its dependent libraries are statically linked to remove their dependence on the execution environment (the current root file system). Finally, the root file system is switched to the target file system and the non-real-time system services in it are loaded.

[0147] Based on the design concept of the aforementioned method, this invention also provides a diverse configurable embedded system bootloader, including a processor, a memory, and a computer program stored on a medium such as the memory, wherein the processor executes the computer program to implement the aforementioned method. Figure 5 As shown, a feasible implementation includes an embedded microprocessor, which includes a memory management unit, an instruction cache, and a data cache. The memory management unit is connected to the instruction cache and data cache inside the microprocessor, and also interacts with system memory and external memory outside the microprocessor.

[0148] It should be noted that any process or method description in the flowchart or otherwise described herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which the embodiments of the invention pertain.

[0149] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, then editing, interpreting or otherwise processing it as appropriate, and then storing it in a computer memory.

[0150] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0151] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0152] Furthermore, the functional units in the various embodiments of this invention can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a hard disk, or an optical disk, etc.

[0153] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A diversified and configurable embedded system boot loading method, characterized in that: The method includes the following steps: Phase 1: Initialize the hardware and set up the environment. Establish the high-level language runtime environment and perform the first relocation without relying on system memory to ensure that the system can transition normally to the subsequent steps and load the hardware debugging user interface. Phase Two: After debugging, the parameters are stored in the flash memory parameter area. During the regular memory initialization process, the parameters are loaded and a second relocation is performed to completely move the runtime environment to memory. At this point, the startup mode is determined according to the preset configuration: In multi-functional mode, Phase Three is loaded and rich advanced features are provided, including: file system support, network support, graphical user interface, advanced diagnostics and repair, and multi-operating system support; In fast startup mode, the process jumps to Phase Four and executes a special process to quickly load the target system and real-time applications. In the second stage, the following specific steps are performed: Step S21: Build a hardware debugging user interface based on the cache that does not depend on the system's main memory; Step S22: Initialize the system memory using the memory parameters obtained during debugging; Step S23: Move the data segment and BSS segment from the cache and flash memory to the system memory respectively, and re-establish the stack pointer at the highest memory address, i.e., the second relocation; Step S24: Move the code segment from flash memory to system memory; Step S25: Release the lock and address space mapping for the data cache; The third stage: Loading the mini system, including a mini operating system and a mini root file system. This mini system serves as the third stage of the bootloader and is used to provide a series of advanced features that traditional bootloaders do not have. This stage will be skipped in fast boot mode. The mini system is a streamlined version of the full operating system, including a minimized operating system kernel and root file system, in order to meet the minimum boot time requirement while supporting various advanced features. Phase 4: Loading the target operating system and applications. In multi-function mode, the target operating system and target root file system are loaded in the mini system context. In fast startup mode, this phase will complete the rapid loading of embedded real-time applications in the shortest time with the assistance of the mini file system, and start other non-real-time services of the target root file system in a delayed manner.

2. The method for booting and loading a diverse configurable embedded system according to claim 1, characterized in that: The first stage involves locking the processor's data cache and mapping it to processor-accessible memory addresses to provide a basic environment for high-level languages ​​to run, independent of main memory. The relocation technique is used to move the data segments required for the execution of the first stage code from flash memory to the corresponding location in the data cache, locate the address of the uninitialized data segment bss in the data cache and perform a zeroing operation, and finally establish a stack pointer at the top of the data cache.

3. The method for booting and loading a diversified configurable embedded system according to claim 2, characterized in that: The first stage specifically includes the following steps: Step S11: Start the embedded system, and the microprocessor begins loading the reset vector stored at a predetermined address on the directly executable flash memory; Step S12: Load the first-stage initialization program to complete the initialization of the processor's on-chip cache; the on-chip cache includes instruction cache and data cache; Step S13: Configure the processor memory management control unit to linearly map the data cache to the processor's accessible space and perform a locking operation to prevent swapping in and out. After the above steps, the data cache is now equivalent to a high-speed static random access memory connected inside the processor. Step S14: Move the data segment from flash memory to the data cache address space, perform a zeroing operation on the BSS segment of the space (i.e., the first relocation), and establish a stack pointer at the top of the data cache; jump the program pointer to the second stage address in flash memory and execute the second stage code.

4. The method for booting and loading a diversified configurable embedded system according to claim 1, characterized in that: Before the first stage, it is necessary to formulate the memory layout and data transfer rules for the bootloader at each stage based on the processor's address access specifications.

5. The method for booting and loading a diversified configurable embedded system according to claim 1, characterized in that: In the second phase, a locking operation is performed on the data cache to prevent the processor from triggering a page fault when the cache access data is missing, as well as from data exchange with the system memory.

6. A versatile configurable embedded system bootloader, comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that: When the processor executes the computer program, it implements the method as described in any one of claims 1-5.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, it implements the method as described in any one of claims 1-5.

Images