KR20140018134A - Fast booting method of operating system from off state - Google Patents

Abstract

Booting in an embedded system increases boot time as complexity increases, performing a series of procedures such as copying executable code from nonvolatile memory to RAM, initializing peripherals, and initializing executable code. To reduce the booting time of non-volatile memory from RAM to reduce the increase of boot time. To reduce the amount of executable code copied, create and copy a partition that collects only the files necessary for initialization. How to initialize the hardware at the same time, improve the device driver to copy the executable code from the repository, improve the way to output debug serials, preload the executables needed by the operating system from the repository, use a fast filesystem In order to satisfy the conditions for the application program to operate when the operating system is initialized, fast booting is performed by performing the selected parallel initialization rather than the sequential initialization.

Description

Fast boot method of operating system from off state {FAST BOOTING METHOD OF OPERATING SYSTEM FROM OFF STATE}

The present invention relates to a method for speeding up the booting speed of an operating system, and more particularly, to a method for enabling fast booting of an operating system from an off state.

As mobile devices become more popular, the demand for longer battery life and immediate accessibility is increasing. Due to the complexity of a full operating system, such as Microsoft's Windows-based operating system, meeting this need is quite difficult. For example, Windows CE, an embedded operating system provided by Microsoft, boots in approximately 12 to 16 seconds from the off state, so it is clearly not considered an immediate accessible device.

Embedded systems, such as PDAs, PMPs, AVNs, navigation, electronic dictionaries, black boxes, and wall pads, will run specific applications that meet the purpose of the product. Mechanisms have been tried to make these applications run faster. Embedded systems also store the executable code and the data of the running program in nonvolatile memory. Non-volatile memory is mainly used NOR Flash Memory, NAND Flash Memory or SD Memory Card. When the embedded system is powered on, a bootloader in nonvolatile memory initializes several types of hardware devices mounted on the board and transfers control to the kernel of the operating system. NOR Flash Memory has the function of execute in place (XIP), which gives the control right to execute without having to copy Bootloader and operating system execution code to RAM. NAND Flash Memory and SD Memory Card have XIP function. Since the initial boot code on the CPU is initialized to allow RAM to operate, the bootloader existing in NAND Flash Memory or SD Memory Card is copied to RAM, and the bootloader copied on RAM Give control. Bootloader on RAM also copies the operating system code from NAND Flash Memory or SD Memory Card to RAM and transfers control to the kernel of the operating system copied onto RAM. NOR Flash Memory is expensive, has a small storage capacity, and takes a long time to write to media. Therefore, in recent years, manufacturers use a lot of NAND Flash Memory or SD Memory Card to store the execution code and program data. Since NAND Flash Memory or SD Memory Card does not have XIP function, it is necessary to copy from stored non-volatile memory to RAM, which takes some time.

To reduce the time it takes to copy at boot time, Windows CE provides a technology called MULTIXIP and BINFS that allows you to copy only part of the operating system, rather than copying the entire operating system code. This takes about 10 seconds on average, which is not enough to be considered a solution either.

In addition, some non-volatile or battery-powered systems provide power to keep the code or data copied to RAM continuously to reduce the time required to copy from nonvolatile memory to RAM. If present, it supports the use of a warm-boot method that does not copy data from non-volatile memory, such as NAND Flash Memory or SD Memory Card, that is not supported by XIP to RAM, thereby providing adequate instant-on performance. Is achieved. However, a warm boot consumes battery power, which is a concern for many users and device manufacturers, and at least for that reason, the use of warm boot is an insufficient solution for many users. It is also a concern for some users and manufacturers that a warm boot can degrade over time.

In addition, after the kernel of the operating system is executed, the kernel initializes many functions of the operating system and executes the desired final applications. Since the operating system has many functions, it takes a long time to initialize these functions. It is also a problem.

Even in embedded systems that are not battery powered, the rapid power-on experience is becoming a very popular requirement. For example, as PDAs, navigation and AVN evolved to provide entertainment, the need for them to behave like regular consumer electronics is increasing. For example, a typical home appliance, as described above, does not take 15 seconds for a tedious boot sequence, but operates within a few seconds to function.

In general, a faster boot from a fully off state is highly desirable for embedded systems.

In an embedded system, booting is the process of initializing the system and executing the desired applications to run the applications that the system is intended to run. In the present invention, a boot sequence for switching an embedded system from an off state to a power-on state is redefined so that applications can be executed quickly after power is applied.

In XIPKERNEL, only the files needed to run GWES are collected. The necessary files are placed in the MODULES area and are not compressed. (WINCE ONLY) On an embedded device, a partition containing KERNEL for fast booting from a WINDOWS CE OS image consisting of several binary partitions contains all the files needed for the GWES Manager to operate, and the executable file is placed in the MODULES area. The file is configured uncompressed.

To speed up booting, LAUNCHER first loads the DLLs of programs needed for other applications. (Technology about preloading, WINCE ONLY) By loading the necessary modules into another (B) application which is faster at boot time from the WINDOWS CE OS image, it is possible to reduce the preparation time for execution of the above program (A Use an application called). The (A) application program is an application program that is executed before (B) and does not terminate before the execution of (B).

Use the KERNEL MODE BLOCK DEVICE DRIVER. (The execution of SECTOR HANDLING is performed in the ISR of KERNEL.) In performing the read / write of the storage, the block operation unit is placed in the ISR of the KERNEL, and the BLOCK DEVICE DRIVER requests the storage operation from the execution unit. The performing unit performs an operation on the storage according to the INTERRUPT, when the request of the BLOCK DEVICE DRIVER is completed, notifying the BLOCK DEVICE DRIVER of the request completion signal, the BLOCK DEVICE DRIVER completes all the processing to the file system Is a block device driver comprising the step of notifying.

 ISR (d), DEBUG MSG API, which calls DEBUG MSG INTERRUPT HANDLER (c), (c) to put DEBUG MSG FIFO BUFFER (a), UART IP FIFO (b), (a) in RAM Use debug message transmission with (e). If a transmission request of DEBUG MESSAGE occurs, save it to DEBUG MSG FIFO BUFFER through DEBUG MSG API and call DEBUG MSG INTERRUPT HANDLER. In the DEBUG MSG FIFO BUFFER, if there is data to be transmitted, the step of transmitting the data of the DEBUG MSG FIFO BUFFER to the UART IP FIFO, and if the UART IP FIFO is full in the DEBUG MSG FIFO BUFFER, is terminated without transmitting.

As a way to configure GWES to boot without dependencies in DEVICE.EXE (WINCE ONLY), in an embedded device using WINDOWS CE OS, the execution module of GWES does not have a relationship with the device driver managed by the device manager. On embedded devices using WINDOWS CE OS, using the GWES startup method, which sets up the registry so that there is no device manager and DEPENDENCE so that the initiation of a GWES manager run can be started without involving the device manager shutdown. If the device driver (A) needs a device driver (B) managed by the device manager, list the device driver (B) in Boot.hv of HIVE BASED REGISTRY and set the registry to run the device manager in bootphase 1, The initiation of a GWES Manager run is related to the end of the Device Manager. So that the device manager and DEPENDENCE to be started without the use GWES start how to set up the registry.

The present invention reduces the time required by reducing the amount of executable code copied from nonvolatile memory to RAM for booting, simultaneously performing copying from nonvolatile memory to RAM and initialization of peripheral devices, and copying from nonvolatile memory to RAM. Use the improved Block Device Driver to improve performance, improve debug serial message handling for debugging, use the method of preferential loading of executable files required for the execution of the application, and parallel initialization or delay of device driver initialization. The use of the method of initialization and the requirements for the application to operate are initialized before other requirements so that the desired end applications can run quickly.

According to the present invention, the final application that matches the manufacturer's intention in the embedded system can be executed quickly after power-on.

In addition, it is expected to increase the standby time of the battery-powered embedded system since it is not necessary to power part of the system to reduce the boot time of the embedded system.

1 is a flow chart of a general OS
2 is a diagram illustrating execution of a file in a storage device being loaded into RAM for execution in general.
3 is an exemplary diagram showing that an OS binary composed of several partitions is loaded into RAM for execution.
4 is an exemplary diagram for loading into RAM to execute a file in the FILES area.
5 is a registry that records the order in which the administrator program and the launcher are executed in the WINDOWS CE environment.
Figure 6 is a registry of the order in which they are executed to start the user interface early in a WINDOWS CE environment.
7 is a boot timing diagram according to the registry for quickly starting the user interface.
8 shows a method for recording the contents of the registry in boot.hv in the WINDOWS CE environment.
FIG. 9 is a diagram illustrating re-arrangement of various programs in VIRTUAL state using MMU when various programs are loaded into RAM.
10 is a timing diagram when using and not using a pre-loading technique.
11 is a flow chart and components of a debug message output unit;
12 is a flow chart and components with improved debug message output;
13 is a general operation timing diagram of a block device driver
14 is an operation timing diagram of an enhanced block device driver using DMA and interrupt;
15 is a delay timing diagram of an enhanced block device driver based on a context switch and thread priorities;
16 is an operation timing diagram of a kernel mode block device driver in charge of IST of a block device driver in a kernel;
17 is a general boot timing diagram.
18 is a boot timing diagram for loading delayed by the device manager.

Embedded systems (especially embedded systems that use Microsoft's WINDOWS CE operating system), when powered on, will initialize the operating system and run the final application following a boot procedure.

1 is a flowchart illustrating a booting procedure of an embedded system device. When the power is applied, Micom FW in the AP loads the boot loader into RAM to execute the boot loader, and the boot loader loads the OS binary into RAM to execute the OS binary. When OS binary is executed in RAM, kernel included in OS binary executes final program after basic initialization.

Depending on the type of nonvolatile memory, executable code may be executed in nonvolatile memory or in RAM. NOR Flash Memory with the function of Execute In Place (XIP) can be executed in the nonvolatile memory itself without being copied to RAM. Non-volatile memory without the function of XIP should be copied to RAM and executed. Non-volatile memory that does not have XIP functions include NAND Flash Memory, SD Memory, MMC, and eMMC.

MULTIXIP  On by XIPKERNEL  Only loading

In general, copying from nonvolatile memory to RAM takes a lot of time. Therefore, attempting to reduce the copy time from nonvolatile memory to RAM is a good way to reduce boot time.

OS binaries made up of multiple binary partitions can only copy a small partition containing KERNEL to RAM and reduce the copying time by allowing KERNEL to run. The technologies for this purpose are MUCHIXIP and BINFS in WINDOWS CE. MULTIXIP is a technology that stores several executable code containing an operating system in multiple partitions, and BINFS is a file system that recognizes this in the operating system's file system. Using MULTIXIP to configure the most basic initialization of the operating system to run can greatly reduce the time it takes to copy from nonvolatile memory to RAM for booting. This also applies to systems such as LINUX, where a binary partition containing the core KERNEL exists and the rest of the files required for operation are organized into filesystems and loaded at boot time.

2 illustrates copying and booting a binary from a general nonvolatile memory NAND Flash to RAM. For example, if the copy speed of NAND Flash Controller is 10MB / sec, it takes 0.1 seconds to copy the bootloader with 1MB of MICOM FW to RAM and 4 seconds to RAM copy the OS with 40MB of bootloader. KERNEL will run about 4.1 seconds after power on.

However, if it consists of several binary partitions as shown in FIG. 3 and the name of the partition containing KERNEL is called XIPKERNEL and the size of the XIPKERNEL partition is 10 MB, copying takes about 1.1 seconds and KERNEL is about 1.1 seconds after powering on. You can start This is about 3 seconds faster than a single partition.

The files needed to boot XIPKERNEL  Put in

The time to copy the contents of nonvolatile memory to RAM is generally faster in the boot loader than in the OS running. The reason is that while the OS is in a multitasking environment, the time taken by the block device driver to occupy the CPU core is less than that of the boot loader, and the high priority TASKs are set by the Context Switch and TASK scheduling policy to change the execution TASK. This is because more time is allocated.

Making MULTIXIP smaller at boot time will speed up the startup of KERNEL, but if KERNEL needs to load additional files because the files needed for initialization remain in nonvolatile memory, additional time of driver loading is required for KERNEL initialization. This can be a barrier to fast booting.

Therefore, if KERNEL is executing code required during initialization or data file is placed in XIPKERNEL area with KERNEL, the time delay for loading executable code from nonvolatile memory during KERNEL initialization can be reduced.

The files and order that KERNEL needs during booting are known to the general engineer working with OS KERNEL, so I won't explain it here. Therefore, if only the files needed for booting and initialization, not all binary files, are located in the partition area containing KERNEL, the time taken for KERNEL to initialize is the same and the loading time from non-volatile memory can be shortened, thereby reducing boot time.

XIPKERNEL  The executable file required for MODULES  Leave it in the area and do not compress it.

In WINDOWS CE, there is a MODULES area and a FILES area. The MODULES area is mainly for the execution code, and the FILES area is for the execution code and data files. The MODULES area is a form where the execution addresses are linked so that the CPU core can run directly from the location.

4 is a diagram illustrating copying a file in the FILES area to an execution area of RAM for execution. If there is executable code in the FILE area, it takes additional time because it must be copied to the execution area of RAM for execution. Therefore, placing the executable files necessary for booting in the MODULES area rather than the FILES area can shorten the boot time.

Files in the FILES area may be compressed in code. In general, the compressed code takes time for the CPU Core to decompress. When booting, the CPU core is heavily loaded, so boot-related files in the FILES area can be booted faster if they are not compressed.

The general setting of compression options in WINDOWS CE, how to set each file, and how to set the files in the FILES and MODULES areas will be omitted by ordinary WINDOWS CE engineers.

On preloading  Related Technologies

The CPU of an embedded device that performs multitasking has a device called a memory management unit (MMU). The MMU is a processing device that manages and controls the access of the main memory. The MMU has a function of converting a logical address and a physical address, an exchange of data, and a memory protection function.

FIG. 9 shows that an executable file loaded in a physical address of a RAM by the MMU and a RAM / STACK of a program are mapped to a virtual address.

In FIG. 9, the A and B application programs interspersed in the physical address exist at the same address position in the virtual address through the MMU. In Windows CE, a DLL file is loaded only once and resides at the same address location in the virtual address of all applications.

For example, if A application needs C.DLL and D.DLL, and B application needs C.DLL, D.DLL, and E.DLL. When an application called A is executed, C.DLL and D.DLL are loaded. After that, if the application called B is executed while the application called A is not terminated, C.DLL and D.DLL are already loaded, so only E.DLL is loaded and executed. If application A is terminated before application B is executed, C.DLL and D.DLL must be unloaded and reloaded when application B is executed. The application is preferably running at all times while the embedded system is running.

In FIG. 10, if the application A has preloaded the E.DLL to be used by the application B when the file system is idle, the application B can save time to start loading the E.DLL. When these load times are collected, the execution time of programs can be shortened at boot time, so that the booting time can be completed quickly.

In WINDOWS CE, A application can use the LoadDriver or LoadLibrary APIs to load arbitrary DLLs into the execution region.

While preloading the DLL of application B while application A is running, the CPU core needs to continue running application A. Therefore, an improved block device driver with less CPU core in loading the DLL from the file system is required. It is preferable to use. The improved Block Device Driver will be described later.

Boot loader Multitasking  To RAM to  Simultaneous initialization of other devices during copying

In the OS of the embedded system, the Device Driver performs the power-up and reset of the H / W device upon initialization, starts the IST (Interrupt Service Thread), and initializes various variables. Powering on and resetting the H / W device requires a time delay due to H / W requirements.

In addition, the boot loader takes a lot of time to copy the binary partition where the OS is installed from the nonvolatile device to RAM.

If the bootloader can copy the OS to RAM and execute H / W device power-up and RESET at the same time, the device driver only needs to perform the rest of the initial stage, thus reducing the boot time.

The bootloader can be configured to multitask by copying, powering up the H / W device, and resetting at the same time. This can be done using a micro RTOS or TINY KERNEL from WINDOWS CE.

In a multitasking environment, the main task is responsible for powering up and resetting the H / W devices, and the other TASK uses the DMA and BLOCK TRANSFER functions of the INTERRUPT method to prevent the CPU core from using much time. Copy from RAM to RAM at the same time.

Block Device Driver

In general, the role of the block device driver is a device driver used to read / write / erase data in a specific page of the repository. Filesystems such as BINFS, FAT, FAT32, NTFS, YAFF, etc. exist on the top, and access the storage through the Block Device Driver.

13 is an exemplary diagram for reading a general Block Device Driver. When a read request for a specific page comes in, the Block Device Driver sets the sector address (a) and requests a read command from the repository. After that, the storage notifies the CPU core that it is in the process of reading the page through the (b) busy signal and releases the busy signal when it is ready to read. In general, busy signals are connected by hardware and can be detected using INTERRUPT. When ready to read, the CPU reads the data in (c) the storage in a certain size and stores it in RAM. After saving, it checks for ECC error and finishes the read operation. The general block device driver detects the busy signal and allocates CPU core to read the data. When a read request is made, other programs do not allocate the CPU core and do not operate smoothly. The other commands of the Block Device Driver, write and erase, operate in a similar manner to the above.

Enhanced Block Device Driver

The Enhanced Block Device Driver loads the CPU Core when loading files from the repository, and the CPU Core is a Block Device Driver that can allocate a lot of time to execute other TASK in addition to loading data from nonvolatile memory.

Recently, an application processor (AP) is equipped with an IP for an INTERRUPT and a DMA controller in addition to a CPU core. The DMA controller is configured to move the data as set and notify the CPU core whether or not to shut down, even if the CPU core is not involved. The CPU core simply plans to operate the DMA controller and performs subsequent processing upon termination to perform copying. You can have free time to run other programs.

14 is an exemplary operation diagram of an enhanced block device driver. Enhanced Block Device Driver (a) sets the sector address to read and requests read command to storage and waits for INTERRUPT of NFC (Nand Flash Controller). During the waiting time, another TASK can operate. (d) When the NFC INTERRUPT occurs, the Block Device Driver gets control again, sets up the DMA controller, requests to start copying from nonvolatile memory to RAM, and waits for the copy to be completed. After copying is completed by the DMA controller, the Enhanced Block Device Driver performs ECC checking. Then (a) the address of the other sector is set again, and the above operation is repeated until the processing is completed for all sectors. When using Enhanced Block Device Driver, Block Device Driver operates only at INTERRUPT EVENT and other TASK occupies CPU Core at other time. Therefore, CPU Core has time to perform other TASK. This is useful for fast boot so that you can initialize it at the same time as other TASK. In addition, since the device can use the storage while the device is operating after booting, it can allocate less time to the CPU Core and more time to other TASKs, which improves the usage environment of the device.

Kernel Mode Block Device Driver

15 illustrates time and operation for reading one SECTOR of the Enhanced Block Device Driver. In the example diagram, CS (Context Switch) occurs when switching between IST, TASK, and ISR. In CS (Context Switch), the AP (Application Processor) with MMU attempts to convert to another CONTENT in MMU TABLE. Several CPU clocks are required and time consuming to reconfigure the operation and MMU settings for CACHE during CS (Context Switch) time.

The operating system of the embedded system also has an algorithm that prioritizes TASK execution when multiple TASKs are multitasking. This algorithm ensures that TASK with higher priority runs before TASK with lower priority. The function that receives INTERRUPT in KERNEL is called Interrupt Service Routine (ISR) and THREAD waiting for INTERRUPT in TASK is called Interrupt Service Thread (IST). Even if INTERRUPT occurs due to THREAD priority, execution is delayed until the execution of high priority THREAD is completed if the THREAD priority of IST is low. This is called Task Priority Delay (or Interrupt Latenance). The delay time is variable and may be a few ns short but may be a few ms long. This delay is a factor that hinders the performance of the Block Device Driver.

FIG. 16 illustrates the operation and timing of the Kernel Mode Block Device Driver to prevent the performance of the Enhanced Block Device Driver caused by the delay. Kernel Mode Block Device Driver performs CS (Context Switch) occurrence count and Block Device Driver by setting sector address, DMA controller setting, ECC inspection, etc. which were processed in IST of Block Device Driver through KERNEL's ISR. Can reduce the time delay.

If the file system wants to copy the data of several sectors in non-volatile memory, the Block Device Driver sends these commands to the Kernel Mode Block Device Driver in KERNEL, and the Kernel Mode Block Device Driver sends the INTERRUPT until all requests are completed. Whenever it is called, the processing service for the sector SEC is performed, and when the processing of all the sector SEC is completed, the IST of the block device driver is called to terminate the processing of the command of the file system.

The Kernel Mode Block Device Driver implemented in KERNEL's ISR is faster than the Enhanced Block Device Driver implemented in IST, and can process more commands such as storage read / write and allocate more CPU Cores to other TASKs. It can be initialized to help boot faster. In addition, since the device can use the storage while the device is operating after booting, it can allocate less time to the CPU Core and more time to other TASKs, which improves the usage environment of the device.

Variable of storage Access Timing  apply

H / W timing is an important determinant of the copy speed for accessing data in non-volatile storage. The faster the timing, the faster the data transfer, but in some cases, errors may occur. Therefore, it is very important to find and apply the best fast timing during the optimal operation.

Debug Message  Speed up processing

Embedded system devices have a variety of debugging methods for monitoring their operation. Various physical devices are used for debugging, such as debugging using Ethernet, debugging using USB, and debugging using serial. Debugging message output runs very slowly compared to the CPU, so a lot of debug messages make the CPU very slow, resulting in longer boot times and slower devices during operation. For example, if the function sending the debug message waits indefinitely until the FIFO of the UART IP is empty, the CPU will not be able to run another TASK while waiting. In addition, manufacturers need to debug the mass-produced products, so they adopt a lot of debugging methods using serial messages in the final stage of product development.

11 illustrates serial debugging provided by a general embedded system. FIG. 11A shows that the DEBUG MSG WRITE FUNCTION 122 and the UART IP FIFO 125 are provided for serial debugging. As shown in (b) of FIG. 11, the number of UART IP FIFOs 125 is limited. Therefore, in order to send many messages at once, the UART IP FIFOs 125 need to overflow and wait a lot of time. 11C is a flowchart of the DEBUG MSG WRITE FUNCTION 122. When the API is called in the flowchart, it keeps checking whether the transmitted DEBUG message remains and the FIFO buffer is available and repeats until all debug messages have been sent.

FIG. 12A illustrates an example of improving a method of transmitting a debug message so that the load on the CPU is small. Add DEBUG MSG FIFO BUFFER (121) to RAM, add DEBU MSG INTERRUPT HANDLER (123) to put message in DEBUUG MSG FIFO BUFFER to UART IP FIFO (125), which will cause the buffer of DEBUG UART to be empty ISR 124 was added to occur every time. 12 (b) is a flowchart of a DEBUG MSG WRITE FUNCTION. The API for sending the DEBUG MSG is stored in the DEBUG MSG FIFO BUFFER 121 on RAM rather than directly writing to the UART IP FIFO 125. When the INTERRUPT of the DEBUG UART occurs, the ISR 124 calls the DEBUG MSG INTERRUPT HANDLER 123 to transmit the DEBUG MSG FIFO BUFFER 121 to the UART IP FOIFO 125. 12 (c) is a flowchart of a DEBUG MSG INTERRUPT HANDLER. If there is a message remaining in the DEBUG MSG FIFO BUFFER on the RAM, it is checked whether it can be transmitted to the UART IP FIFO 125, and if it can be transmitted, it is transmitted to the UART IP FIFO 125, otherwise the function ends. The main difference from the unimproved API is that it does not wait for the use of the UART IP FIFO 125. FIG. 12 (d) is a flowchart showing that the DEBUG MSG INTERRUPT HANDLER is called when the INTERRUPT occurs in the DEBUG UART and the UART IP FIFO 125 is available. This method is useful for speeding up booting because the CPU Core can spend a lot of time on other TASKs without having to wait for the slow UART IP FIFO 125 to be emptied, and also outputs debug messages while the device is operating after booting. Allocate less time to and more time to other TASKs, which improves the usage environment of the device.

OS After loading

The WINDOWS CE operating system consists of the kernel kernel (KERNEL) and several major core manager programs, modules, system repositories, and applications. The main core manager programs include file system manager, device manager, GWES manager, and communication manager. Modules are small program units used by administrator programs.

FIG. 17 is a diagram illustrating how various SWs boot when a device of WINDOWS CE is booted. In the example, if the boot loader loads KERNEL into RAM and takes control to KERNEL, KERNEL executes the file system manager, driver manager, GWES manager, and CUSTOM SHELL sequentially after initializing.

File system manager is a program that recognizes and manages storage devices, initializes system storage, and executes various core manager programs and applications at boot time. The file system manager can recognize various file systems such as BINFS, FATFS, FAT32, etc. of the storage, and will automatically load the file system as described in “[HKEY_LOCAL_MACHINE / System / StorageManager / AutoLoad]” among the registries that are part of the system storage at boot time. It is responsible for loading.

The device manager is a manager program that manages device drivers for controlling peripheral devices of an embedded system. When a device driver boots, it loads the device driver described in “[HKEY_LOCAL_MACHINE / Drivers / BuiltIn]” in the registry and provides a service that executes the code of the device driver whenever a request is made. After booting, you can load additional device drivers by using ActivateDevice, a system API provided by WINDOWS CE.

GWES Manager is an abbreviation of Graphic / Window / Event / System and it is a program that plays a role for application to draw on the screen and deliver events during operation. When the GWES Manager is running during boot up, it loads the display driver, touch driver for user input and output, and keyboard driver.

The communication manager performs a service with various protocol stacks (STACK) in order to use the Internet communication in the embedded system.

In general, an embedded system has an application called CUSTOM SHELL that wants to repeatedly perform a desired function on the device. In the case of the navigation device, the LAUNCHER application program is an application program that is responsible for the user interface and operation of the device. The navigation device plays a role of calling and executing a route guidance application and a multimedia application program. Applications such as LAUNCGER are designed to run early on the device's boot and continue to run in RAM until the end of the device.

In WINDOWS CE, the kernel (KERENL) runs first when the operating system boots. The kernel initializes main memory, interrupts, timers, and so on, and the file system manager. The file system manager refers to the registry, loads the file system of the repository in the “[HKEY_LOCAL_MACHINE / System / StorageManager / AutoLoad]” item, performs initialization according to BootPhase 0, 1, 2, and “ Run the Device Manager according to the item in “Launch_xx” of [HKEY_LOCAL_MACHINE / Init] ”. There is a key of "Launch_xx" and a key of "Depend_xx" in "[HKEY_LOCAL_MACHINE / Init]" of the registry. "Launch_xx" means to execute the execution module written in the value of the key in the "xx" th, and "Depend_xx" means the value recorded in the "Depend_xx" for the "xx" th execution module. It means that the execution module of 'Start' is completed after execution.

The device manager loads several device drivers at boot time in the order described in the registry [[HKEY_LOCAL_MACHINE / Drivers / BuiltIn]]. The driver calls each driver's XXX_Init () in the registry by loading the values of the “Order” key in the device driver section in descending order.

The device manager uses BusEnum to determine the loading order of device drivers. Improving BusEnum to implement the loading order of the driver as a serial method of loading the next driver after completion of loading the previous driver, a parallel method of loading the driver at the same time, or a delay method of generating THREAD related to loading and later loading by THREAD. BusEnum2 is already introduced. In the case of a device operating with a single CPU Core, parallel initialization during booting is difficult to shorten the booting time, but in a device with multiple CPU Cores, parallel initialization is effective for shortening the booting time.

18 is a diagram showing that various manager programs are initialized according to the time for the delayed loading method. In addition to booting, the device manager first loads device drivers that must be used in the first loading section and programs that are not necessary in the second loading section. User INTERFACE has the effect of being accelerated by the time required for secondary loading.

GWES  Administrator's preferred initialization

5 is a registry of the start of various administrator programs when a typical WINDOWS CE device is booted. Device.exe, the device manager, starts 20th. GWES Manager is the 30th startup, and it runs after the 20th Device.exe is finished. The final device operating program, CustomShell.exe, is the 50th startup and runs after the 20th Device.exe and the 30th GWES Manager have been initialized. In general, the device manager is set to run before the GWES manager in WINDOES CE, the GWES manager is to be executed after the device manager is completed, and the application program is executed after the initialization of the device manager and the GWES manager is completed.

FIG. 17 is a diagram showing, in time, the order in which the apparatus having the registry for FIG. 5 is executed. FIG.

In an embedded system with a touch device as a display and user interface, the initialization of the GWES Manager must be done quickly to enable the user interface first.

6 is a registry of an example for quickly loading a driver used in a GWES manager. The GWES Manager is loaded 30 times but does not wait for the completion of the 20th loaded device manager. Also, the LAUNCHER launcher, CustomShell, does not wait for the device manager's initialization but only waits for the GWES manager's initialization to complete.

FIG. 7 is an expected timing diagram of a program of an embedded device executing the contents of the registry of FIG. 6. In the figure, as soon as the device manager runs, the initialization of the GWES manager starts, and then CustomShell initializes. As shown in FIG. 6, the embedded device applying the registry may quickly start user input / output. As shown in FIG. 6, there are conditions for executing the GWES manager and CustomShell. The GWES Manager will load the display driver, the TOUCH driver, and the KEYBOARD driver. These drivers should not require drivers managed by the device manager. If necessary, change it to not be necessary, or load a device driver that is managed by the required device manager before running GWES Manager.

For example, there are two ways to load the device drivers that are required before running GWES Manager. The first is to use BUSENUM described above. As shown in FIG. 5, the device manager is included in the “Depend” in which the GWES manager is executed by recording the registry, and the execution of the remaining drivers except for the driver necessary for the driver of the GWES manager is performed using BUSENUM.

The second method is to use the HIVE REGISTRY method. HIVE REGISTRY manages the contents of a registry as a file. At boot time, the registry file named boot.hv is first referenced, and then the default.hv registry is referenced to the contents of the file.

8 illustrates how to put the contents of the registry in Boot.hv. The contents between the start sentence "; HIVE BOOT SECTION" and the last statement "; END HIVE BOOT SECTION" are included in the file boot.hv. Write the device driver managed by the device manager necessary to run the GWES Manager in Boot.hv and run the device manager in Bootphase 1, and set the registry as shown in Fig. 6, and the device manager is executed before the GWES manager is executed. It will load the device driver in .hv. At this time, the contents of “Launch” of “[HKEY_LOCAL_MACHINE / Init]” are not put in boot.hv.

The method described above is one example. Various complex applications and various application examples will be possible. It is also possible to combine the above techniques for fast booting. By the above method, the embedded system can save a lot of boot time, and can perform instance-on booting in about 3 to 5 seconds.

Claims (5)

In XIPKERNEL, only the files needed to run GWES are collected. The necessary files are placed in the MODULES area and are not compressed. (WINCE ONLY)
A. In a WINDOWS CE OS image with multiple binary partitions on an embedded device, the partition containing KERNEL for fast booting contains all the files necessary for the GWES administrator to run, the executable file in the MODULES area, and the file in the FILES area. How to configure without compression.
To speed up booting, LAUNCHER first loads the DLLs of programs needed for other applications. (Technology about preloading, WINCE ONLY)
A. How to use an application called (A) that will speed up preparation time for execution of the above program by first loading the necessary modules into another application called (B) at boot time from the WINDOWS CE OS image. .
B. The application (A) is executed before (B) and is not terminated before (B).
Use the KERNEL MODE BLOCK DEVICE DRIVER. (HANDLING of SECTOR is performed in KERNEL's ISR)
A. In performing read / write of storage, put block operation in ISR of KERNEL.
B. BLOCK DEVICE DRIVER requests a storage operation from the execution unit
C. The performing unit performs an operation on the storage according to the INTERRUPT
D. The performing unit notifies the BLOCK DEVICE DRIVER of the request completion signal when the BLOCK DEVICE DRIVER request is completed.
E. The block device driver includes the step of notifying the file system of the completion result when all processing is completed.
ISR (d), DEBUG MSG API, which calls DEBUG MSG INTERRUPT HANDLER (c), (c) to put DEBUG MSG FIFO BUFFER (a), UART IP FIFO (b), (a) in RAM Debug message transmission method with (e)
A. If a transmission request of DEBUG MESSAGE occurs
i. Store in DEBUG MSG FIFO BUFFER and call DEBUG MSG INTERRUPT HANDLER via DEBUG MSG API
ii. Steps to call DEBUG MSG INTERRUPT HANDLER from ISR when DEBUG UART INTERRUPT occurs
iii. In DEBUG MSG INTERRUPT, if there is data to be transmitted to DEBUG MSG FIFO BUFFER, transmitting the data of DEBUG MSG FIFO BUFFER to UART IP FIFO.
iv. Step to exit without transmitting if UART IP FIFO is full in DEBUG MSG INTERRUPT
B. DEBUG MESSAGE transmission method including
How to set up GWES to boot with no dependencies in DEVICE.EXE. (WINCE ONLY)
A. On embedded devices using WINDOWS CE OS
i. The execution module of GWES does not exist in the device driver managed by the device manager.
ii. How to start GWES to set the registry so that there is no device manager and no DEPENDENCE so that the start of a GWES manager's execution can be started without involving the device manager's shutdown.
B. On Embedded Devices Using WINDOWS CE OS
i. If the device driver (A) used by the GWES Manager requires a device driver (B) managed by the device manager, list the device driver (B) in Boot.hv of HIVE BASED REGISTRY and run the device manager in bootphase 1. Set up the registry,
ii. How to start GWES to set the registry so that there is no device manager and no DEPENDENCE so that the start of a GWES manager's execution can be started without involving the device manager's shutdown.

Images