JP2011008688A - Control method for built-in system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To allow, in a built-in system including a device which cannot support a suspend-resume function, the suspend-resume of the system.SOLUTION: In the control method for a built-in system partially including a device which does not support the suspend-resume function, interruption is prohibited for the device from start of suspend processing to completion of resume processing, and when the resume processing is completed, the device is initialized prior to permission of the interruption.

Description

  The present invention relates to a control method of an embedded system, and more particularly to a control method that enables suspend resume of the entire system.

  An increasing number of devices, such as information processing devices, are equipped with a resume function to reduce power consumption. Among them, hibernation does not require a standby current to store a suspend image in a nonvolatile storage area, so that power saving performance is most excellent. If the suspend / resume function is provided, the resume can be returned to the operating state more quickly than the start-up, so that it has power saving performance when not in use and can immediately enter the operating state when it is desired to use it.

  However, an embedded system including a device that does not support the suspend / resume function or a device that has a deficiency in the suspend / resume process of the device driver cannot support the function. In such an embedded system, it is necessary to perform start / end processing each time it is used or to keep it in an operating state. The end of activation every time it is used has the disadvantage that it takes a long time for activation and cannot be used immediately when it is desired to use it. Moreover, there is a problem that the power saving performance is inferior when the system is always operated.

  Conventionally, a method of starting up more quickly has been proposed regardless of the starting method (see, for example, Patent Document 1). This is because when the first computer boots the first operating system using the second boot method, the first computer completes booting of the first operating system after the booting of the second operating system is completed. In the meantime, a second user interface process is performed in which a user's instruction is acquired from input means shared with the first computer, and the first computer uses the first boot method to install the first operating system. When starting, if the execution of the processing of the second user interface is suppressed, the state is changed according to the user's operation, so that the state transits to the suspended state or hibernation as the hibernation state. You can resume from suspend or hibernation. The

JP 2006-355325 A

  Even for embedded systems that include devices that do not support the suspend / resume function, devices that can be loaded and unloaded while the system is running, such as devices that can be removed while the system is running, must be unloaded before suspension. It is possible to apply a technique of loading and reinitializing the device after resuming. However, this method has a problem that it cannot be applied to a device that cannot be unloaded during system operation, such as plug and play.

  Even if the device driver can be modified so as to support the suspend / resume function, the copyright of the driver becomes an obstacle, and the device driver cannot be modified and may not be supported.

  The method disclosed in Patent Document 1 described above requires not only a plurality of CPUs, that is, a host CPU and a real-time CPU, but also cannot cope with a countermeasure for a problem caused by a mismatch between a process and a device.

  Therefore, the present invention has been made in view of the above problems, and there is provided a control method for an embedded system that enables suspend resume of the entire system even in an embedded system including a device that does not support the suspend / resume function. It is to provide.

  According to one aspect of the present invention, there is provided a control method in an embedded system that includes a device that does not support a suspend / resume function as part of the device, from the start of the suspend process to the completion of the resume process. In the meantime, a control method in an embedded system is provided in which interrupts are prohibited, and when the resume processing is completed, the device is initialized and then interrupts are permitted.

  According to another aspect of the present invention, for an application using a device that does not support the suspend / resume function, the device driver is reopened after the system is resumed and before the device is used. A control method in an embedded system is provided, wherein the device driver information is re-read.

  According to the present invention, even in an embedded system including a device that does not support the suspend / resume function, it is possible to suspend / resume the entire system.

1 is a block diagram showing a schematic configuration of an embedded system according to an embodiment of the present invention. It is a figure which shows the layer structure of the embedded system which concerns on this embodiment. It is a figure explaining the example which manages the device not corresponding to a suspend resume function. It is a flowchart which shows the flow of the suspend process in this embodiment. It is a flowchart which shows the flow of the starting process of the kernel before resuming. It is a flowchart which shows the flow of this process of resume.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings. In the drawings, the same portions are denoted by the same reference numerals, and redundant description is omitted.

  FIG. 1 is a block diagram showing a schematic configuration of an embedded system according to an embodiment of the present invention. The embedded system 100 is a computer system that is incorporated into a home appliance or machine in order to realize a specific function. For example, as shown in FIG. 1, a CPU 101, a memory 102, an input device 103, a display device 104, a storage A device 105, an internal bus 106, a power supply unit 107, and the like are provided.

  The CPU 101 is a CPU built in the embedded system 100 and controls the entire embedded system 100.

  The memory 102 is a memory device composed of a volatile semiconductor memory. The memory 102 stores programs processed by the CPU 101 and temporary data.

  The input device 103 is, for example, a keyboard, a mouse, or a touch pad. It is provided in the embedded system 100 and is used to input user instructions such as commands.

  The display device 104 is an LCD display built in the embedded system 100, for example.

  The storage device 105 is an HDD device or an SSD device built in the embedded system 100. A program processed by the CPU 101 is stored in the storage device 105 in advance. In the case of hibernation, the storage device 105 is also used as a place for storing data such as a memory.

  The internal bus 106 is a bus for connecting the constituent units in the embedded system 100 and exchanging data. Each component unit realizes data exchange via the internal bus 106.

  The power supply unit 107 supplies power to each component included in the embedded system 100. Moreover, electric power can be supplied or interrupted for each component as necessary. For example, it is conceivable that power is kept supplied to the memory 102 when shifting to suspend, but the power of other components is cut off.

  In the present embodiment, hibernation control is applied, taking as an example Linux (registered trademark), which is an OS that does not depend on a CPU system and can flexibly support various devices. Generally, an OS includes at least functions of (1) a device driver that manages peripheral devices, (2) memory management, and (3) file system management. The part responsible for the basic functions of the core of the OS is the OS kernel, which operates in a kernel mode that allows access to any part of the computer.

  The functions of the software running on the computer can be seen in a layer configuration. FIG. 2 is a diagram showing a layer configuration of the embedded system according to the present embodiment. As shown in FIG. 2, this layer configuration includes an application layer, an OS layer, a device driver layer, and a hardware layer.

  The application layer is the highest layer and is a software group of an upper layer of the OS.

  The OS layer is a layer positioned below the application layer, and is responsible for the basic functions of the system such as hardware control, management of tasks (work) and file system, connection to a network, and the like. The lower layer in which the OS kernel is operating is called kernel space or kernel mode.

  The device driver layer is a layer in which a device driver for device control is located.

  The device layer is a layer in which each device constituting the computer such as a CPU and a memory and peripheral devices are located. The devices incorporated in the embedded system 100 are usually composed of various specifications. Therefore, in the present embodiment, control is performed separately for a device that supports the suspend / resume function and a device that does not support the suspend / resume function. For example, many HDD devices, SSD devices, USB memories, and the like correspond to devices that do not support the suspend / resume function.

  In the present embodiment, an example will be described in which the suspend / resume function of the Linux (registered trademark) OS hibernation smoothly operates even in the embedded system 100 in which a device that does not support the suspend / resume function is incorporated.

  When the embedded system 100 in which the application is installed is operated and the hibernation control is performed, a so-called malfunction occurs in a device that does not support the suspend / resume function. Thus, according to the earnest and analysis of factors that cause device malfunction, these factors are as follows.

(1) Mismatch between device resources (configuration settings) and hardware settings Generally, device resources and hardware settings are saved and restored before and after hibernation control. However, if the device driver implementation is insufficient and the suspend / resume function is not supported, the driver resource (configuration setting) and the hardware value do not match, which may cause a malfunction.

  Malfunctions in configuration settings include, for example, different register values, mismatched HDD device transfer rates, and different DMA transfer modes.

  Moreover, as a malfunction in the hardware side setting, for example, there is a case where the ON / OFF states of the power supply do not match.

(2) Information mismatch between process and device Even if the state of the device changes before and after the hibernation control, the process cannot recognize it, and there is a possibility that an access or malfunction occurs before the hibernation control. For example, it appears when the pointer value does not match when the driver is opened or when the data in the process resource does not match the data accessed by the driver.

  Accordingly, when the embedded system 100 includes a device that does not support the suspend / resume function, it is preferable to perform hibernation control different from that of the device that supports the suspend / resume function.

  Therefore, in this embodiment, devices that do not support the suspend / resume function are grasped and managed in advance.

  FIG. 3 is a diagram illustrating an example of creating and managing a “devices” file for a device that does not support the suspend / resume function. In the example shown in FIG. 3, a sysfs interface which is a virtual file system provided by a Linux (registered trademark) kernel is used. The sysfs interface exports information about devices and device drivers from the kernel model to user space and is used for configuration. As shown in FIG. 3, a “devices” file is created and managed under the / sys / power directory. <device number> is the device name of a device that does not support the suspend / resume function. Therefore, since it is not necessary to apply the control method according to the present embodiment to a device that can support the suspend / resume function, normal suspend / resume processing is performed without displaying the device in the “devices” file. In FIG. 3, device name = 0 (normal suspend / resume processing is performed) and device name = 1 (initialization is performed) are shown.

  Next, the suspend process in the control method of this embodiment will be described. Suspend processing performs process, device, virtual console, and CPU stop processing, creates a suspend image from the memory in that state, returns the device, virtual console, and CPU to the state once, and then suspends the image to the swap area. Write. Thereafter, the process is terminated by turning off the power of the system.

  For a device that does not support the suspend / resume function and is managed by the table shown in FIG. 3, the interrupt is prohibited when the device suspend process is performed, and the subsequent processes are not performed. Suspend processing is performed while access from the process is prohibited.

  The flow of suspend processing in the control method of this embodiment will be described below with reference to FIG. As shown in FIG. 4, first, the virtual console is set for suspend processing (step S401). For example, the control screen is switched by a key operation. Next, the process and the kernel thread are stopped (step S402). Next, the memory is collected and a process specific to the CPU series is executed (step S403). Next, the virtual console is suspended (step S404). Thereafter, it is determined whether or not the suspend / resume function is not supported for each device included in the embedded system (step S405). If the device supports the suspend / resume function, the suspend process is executed for the device (step S406). If the device does not support the suspend / resume function, the interrupt of the device is prohibited (step S407). Next, CPUs that are not used for startup (booting) are stopped (step S408). Next, a suspend image that is the entire saved data at the time of suspend is created (step S409). Then, the stopped CPU is restored (step S410), and processing unique to the CPU series is executed (step S411). Thereafter, it is determined whether the device does not support the suspend / resume function (step S412). If the device supports the suspend / resume function, the resume process is performed for the device (step S413). If the device does not support the suspend / resume function, the resume processing is not performed for the device. Next, a resume process is performed for the virtual console (step S414). Next, the suspend image is written into the swap area (step S415). Then, the system is powered down and the suspend process is completed (step S416).

  Next, the resume process will be described. The resume process is executed after the kernel startup process. First, it is checked whether a suspend image exists in the swap area. If a suspend image exists, the process is stopped and the suspend image is read into the memory. Next, the suspended image is restored and the CPU register information is restored while the virtual console, the device, and the CPU that is not used for startup (booting) are stopped. Next, the CPU, the device, the virtual console, and the process are resumed, and the resume process ends.

  For devices that are not supported by the suspend / resume function managed in the table shown in FIG. 3 described above, re-initialize at the timing of the resume processing of the device, thereby avoiding inconsistencies between configuration settings and hardware-side settings. . For an application that uses the device, after the system resume process, before using the device, the device driver is reopened, and the device driver information is reread to avoid inconsistencies. After that, the interrupt is permitted and the normal state is restored.

  Note that it is preferable to notify the application of a certain notification after the initialization of the device.

  Further, it is preferable that the device reopens the device driver and rereads the device driver information when one application becomes active immediately after the kernel thread of the process is resumed.

  Below, the flow of the resume process in the control method of this embodiment is demonstrated according to FIG. 5, FIG. FIG. 5 is a flowchart showing the flow of the kernel startup process before resuming. As shown in FIG. 5, first, the boot loader expands the kernel in the memory (step S501). Next, interrupts are prohibited, and machine-dependent units, timers, and page tables are initialized (step S502). Next, initialization of the scheduler is executed (step S503). Next, the interrupt table is initialized and an interrupt is permitted (step S504). Thereafter, initialization of a subsystem such as a bus is executed (step S505). Next, subsequently, the file system is mounted to initialize the root file system (step S506). Next, the device driver is initialized, and the kernel startup process before resuming is completed (step S507).

  FIG. 6 is a flowchart showing the flow of the resume process. As shown in FIG. 6, first, the virtual console is set for suspend processing (step S601). Next, the process and the kernel thread are stopped (step S602). Next, the suspend image is read from the swap area (step S603). Next, the virtual console is suspended (step S604). Thereafter, it is determined whether the device does not support the suspend / resume function (step S605). If the device supports the suspend / resume function, the suspend process is executed for the device (step S606). If the device does not support the suspend / resume function, the interrupt of the device is prohibited (step S607). Next, CPUs that are not used for startup (booting) are stopped (step S608). Next, the suspend image is expanded in the memory (step S609). Then, the stopped CPU is returned (step S610), and processing unique to the CPU series is executed (step S611). Thereafter, it is determined whether the device does not support the suspend / resume function (step S612). If the device supports the suspend / resume function, the resume process is performed for the device (step S613). If the device does not support the suspend / resume function, the device is initialized (step S614), and an interrupt is permitted (step S615). Next, a resume process is performed for the virtual console (step S616). Next, the process and the kernel thread are resumed (step S617). Thereafter, it is determined whether the device does not support the suspend / resume function (step S618). If the device supports the suspend / resume function, the virtual console is returned to the original state and the resume process is completed (step S619). If the device does not support the suspend / resume function, the device is reopened and reread (step S620), and the process proceeds to step S619.

  In some devices, such as serial devices such as console devices and HDD devices used in the hibernation information storage area and root file system, process scheduling is stopped and the kernel executes hibernation processing (suspend / resume). Even when it is running, interrupts do not work because it is used by the kernel, and it works. Therefore, it is necessary to mount these devices so that the device driver can support the suspend / resume function.

  According to the present embodiment, the mismatch between the device driver resource (configuration setting) and the hardware setting is resolved. Also, since the mismatch of pointers and process resources when the driver is opened is resolved, deficiencies can be compensated for in embedded systems that include drivers that do not support the suspend / resume function, so that hibernation control can be performed smoothly. .

  Note that the present invention is not limited to the above-described embodiments as they are, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. Moreover, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the above embodiments. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, constituent elements over different embodiments may be appropriately combined.

  101 ... CPU, 102 ... memory, 103 ... input device, 104 ... display device, 105 ... storage device, 106 ... internal bus, 107 ... power supply unit, 100 ... -Embedded system.

Claims (10)

A control method in an embedded system including a device that does not support the suspend / resume function as a part thereof,
For the device, the interrupt is prohibited from the start of the suspend process to the completion of the resume process, and the interrupt is permitted after the device is initialized when the resume process is completed. Method. For an application that uses a device that does not support the suspend / resume function, the device driver is reopened and the device driver information is reloaded after the system resume process and before using the device. The method of controlling an embedded system according to claim 1.   3. The embedded system control method according to claim 2, wherein after the device is initialized, a predetermined notification is notified to the application.   3. The device reopens the device driver and rereads the device driver information when one application becomes active immediately after the kernel thread of the process is resumed. The embedded system control method described.   3. The embedded system according to claim 2, wherein the device reopens the device driver and rereads the device driver information before using the device after restarting a kernel thread of a process. Control method.   The prohibition of the interrupt means that the interrupt is prohibited when the suspend process of the device that does not support the suspend / resume function is performed, and the suspend process is performed while the subsequent process is not performed and the access from the process is also prohibited. The method for controlling an embedded system according to claim 1, wherein the embedded system is controlled.   7. The device that does not support the suspend / resume function is reinitialized at the timing of the resume process of the device to avoid a mismatch between the configuration setting and the hardware side setting. The embedded system control method according to any one of the above.   8. The embedded system control method according to claim 1, wherein the device that does not support the suspend / resume function creates and manages a file.   The embedded system control according to any one of claims 1 to 8, wherein a normal suspend / resume process is executed for a device supporting the suspend / resume function without prohibiting an interrupt. Method.   The embedded system control method according to any one of claims 1 to 9, wherein the embedded system is controlled by a Linux (registered trademark) OS (operating system).

Images