JP2014531099A - Switching operating context - Google Patents

Abstract

Multiple operational contexts are invoked from the standby power state of the computing device. The operational context is executed on one or more operating systems of the computing device. When a desired operating context is selected, such as by user initiated behavior or activation through a hot key, an operating system that supports the desired operating context is booted up from a standby power state. [Selection] Figure 1

Description

  There are mechanisms to conserve power by suspending computer execution and implement multi-boot computing devices. In prior art systems, one operating system (OS) is usually booted at a time. If a second OS is required, the computing device is powered off and the firmware is rebooted. There may be standards for a boot process such as a basic input / output system (BIOS) boot specification and / or an extensible firmware interface (EFI) boot manager.

  In addition, there may be standards and specifications for power management of computing devices. For example, the US Energy Star rating provides an exemplary requirement for a machine (computing device) to consume only 100 watts. Advanced Configuration and Power Interface, or ACPI (Advanced Configuration & Power Interface) (see http://www.acpi.info), is used to identify standards for power management by Intel, Microsoft, Toshiba, And an industry specification jointly developed by Hewlett-Packard. Sleep states and transitions are defined by the ACPI specification. For example, there is an ACPI specification that defines how the hardware is built to support S4 sleep or hibernation. In the S4 sleep state, the computing device goes into deep sleep and saves power. In the S4 sleep state, the OS of the computer device extracts all memory contents and saves them in a disk file (hard disk). Another state is the S3 sleep state, which is considered a standby state. In S3, the contents are held in the system's random access memory (RAM). A small amount of power is provided to the system RAM and chipset to catch or listen for a return event such as a laptop lid being opened or hot key activation. In contrast, everything is turned off in the S4 sleep state.

  Computing devices can use multiple operating contexts and applications run on the same OS or different OSs. For example, the user can play a game running on a first OS such as a Windows (registered trademark) OS. Game play is one action context. Next, the user wishes to use a touchpad running on a second OS, such as the Linux (registered trademark) OS. A touchpad application is another operational context. The switching of operating context can include events such as closing the lid of the laptop computing device or activating a designated hot key of the computing device. Considering that switching of operation contexts includes shutting down one OS and starting another OS, the time between the operation contexts may be long. It is highly desirable to switch operating contexts quickly with minimal delay. It should be understood that a virtual machine running on a computing device can provide minimal delay between operational contexts. Virtual machine execution requires large computing resources and power of the computing device. This can be a problem when the computing device has limited resources, including power resources. This is especially true when the computing device is a small form factor device such as a tablet or ultrabook. Therefore, it is desirable to be able to switch operating contexts with minimal delay, computing resources, and power.

  The detailed description is described with reference to the accompanying figures. In the figure, the leftmost digit (s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.

It is an example of the flowchart which switches an operation context. It is an example of the flowchart which performs an operating system, when switching an operation context. 10 is an example of a flowchart for starting and executing a system management (mode) interrupt or SMI handler when switching between operation contexts. It is an example of the flowchart holding the operating system context switched when switching an operation context. It is an example of the flowchart which restarts a target switching context when switching an operation context. It is an example of the flowchart which jumps to an operating system restart vector when switching an operation context. FIG. 10 is an example of a flowchart for returning from a sleep state in a pre-extensible firmware interface (Pre-EFI or PEI: Pre Extensible Firmware Interface) implemented in a basic input / output system (BIOS) when switching between operation contexts. FIG. 6 is an example of a flowchart for returning from a sleep state in a driver execution environment (DXE) implemented in a basic input / output system (BIOS) when switching between operation contexts. FIG. 2 is a block diagram of an example of a computing device architecture that implements switching of operating contexts. It is a block diagram of an example of the memory which implements switching of an operation context.

  The switching of the operation context in the computing device uses a low power state such as a standby state, that is, an S3 sleep state. By using the low power state, the operation context switching and / or operation context invocation time can be minimized.

Overview Described herein are methods, computing devices, and computer-readable storage media that implement a low power state to enable switching (eg, changing) of operating contexts on a computing device. Typically, a standby state, such as the S3 state, is used for one process and one instance, but the present specification describes a method, computing device, and computer readable method that uses the standby state, or S3 state, for N operational contexts. A storage medium is described. For example, the operation context can be switched in a time efficient and responsive manner using the standby state, that is, the S3 state. The operation can be platform independent or OS independent and is implemented using the basic input / output system (BIOS) of the computing device.

  In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, those skilled in the art will appreciate that the invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the present invention.

  Some portions of the detailed descriptions that follow are presented in terms of algorithmic and symbolic representations of operations on data bits or binary digital signals within a computer memory. These algorithmic descriptions and representations can be the techniques used by those skilled in the data processing arts to convey the substance of their work to others skilled in the art.

  Except where otherwise specified, as will be apparent from the discussion below, throughout this specification, considerations utilizing terms such as “processing”, “computing”, “calculation”, “decision”, etc. Manipulate data represented as physical quantities, such as electronic quantities in a register and / or memory of a computing system, and / or memory, registers, and other such information storage or transmission devices of a computing system It is understood that it refers to the operation and / or process of a computer or computing system or similar electronic computing device that translates into other data that is also represented as physical quantities within. A term that does not specify a quantity ("a" or "an"), as used herein, is defined as one or more. The term plural is defined as two or more as used herein. The term another, as used herein, is defined as at least a second or a third or more. The terms including and / or having, as used herein, are defined as including but not limited to. The term coupled as used herein is operably coupled in any desired form, eg, mechanically, electronically, digitally, directly, by software, hardware, etc. To be defined. It should be understood that the present invention can be used in a variety of applications.

  Some embodiments may include various devices and systems, such as personal computers (PCs), desktop computers, mobile computers, laptop computers, notebook computers, tablet computers, server computers, handheld computers, handheld devices, personal information terminals. (PDA) device, handheld PDA device, on-board device, off-board device, hybrid device, vehicle device, non-vehicle device, mobile device or portable device, consumer device, non-mobile device or non-portable device, wireless communication base station, And / or can be used in conjunction with a wireless communication device. Herein, such devices are collectively referred to as “computing devices”.

  The computing device implements a low power state, for example, the computing device may use the ACPI specification and enter an S3 sleep state or standby state. The computing device includes one or more OSs including a “complete” OS, a dedicated OS, an OS / application, etc. An application running on a computing device can run in its own operating context. Each OS and operating context is compatible with or utilizes a low power state (eg, a standby state or S3 state). The operational context or OS can be invoked by a user action such as closing the lid of the laptop computing device and / or activating a hot key of the computing device, or separated from an OS / operational context. The OS / operation context can be switched to. It should be understood that other trigger events may be implemented that are pre-programmed and / or integrated as part of a computing device and / or programmed by a user.

  The described methods and processes may be implemented as part of a basic input / output system (BIOS) of a computing device. In addition, the computing device implements certain BIOS boot specifications and / or extensible firmware interface (EFI) boot manager specifications. The method and process may also utilize a System Management Mode (SMM) interrupt (SMM) operation, particularly a defined SMM operation that includes an SMI handler. The SMI handler is particularly related to detecting an “error” and dealing with the error when booting the OS.

Example Process Referring now to the drawings, FIG. 1 illustrates an example process 100 for switching operational contexts. In block 102, it is assumed that the computing device is powered on, but the computing device can be in one of several sleep states. It is determined whether the computing device is in a standby state, eg, an S3 sleep state. In particular, at block 104, it is determined whether the computing device resumes from a standby state, ie, an S3 sleep state.

  If the computing device has not been resumed from the standby state, ie, the S3 sleep state, the “NO” branch of block 104 is followed, and at block 106 the computing device reserves resources for the target OS, and the target OS It is defined as the OS that the device should use for a specific operating context. At block 108, resources for OS switching context are reserved. For example, the OS can be switched from a Windows (registered trademark) OS to a Linux (registered trademark) OS. At block 110, the desired OS is started.

  If the computing device comes from the standby state, i.e., the S3 sleep state, the "YES" branch of block 104 is followed, and in block 112 it is determined whether the OS switch flag is set. In particular, at block 112, a determination is directed whether the OS should be switched or changed to support the desired operational context. If the decision is to use the same previous OS, then follow the “NO” branch of 112 and at block 114 a normal resume from the standby or S3 state is performed. Next, at block 110, the OS is started.

  If the computing device 100 should change or switch the OS, it will follow the “YES” branch of block 112 and the computing device will run from another OS's standby or S3 state in another OS. Move to the operation context to be executed. Therefore, it is necessary to restore or boot up the other OS.

  At block 116, the OS switch flag is cleared for maintenance purposes. At block 118, an update to the boot target is performed. For each OS, memory is reserved for booting up each OS. Resume is performed from each memory location of the desired OS. In block 120, resources for the target OS are reserved. In block 122, an override from the boot mode to a full boot of the target / switched OS is performed. At block 124, during the BIOS of the computing device, a boot is performed to start a different OS or target OS. At block 126, the target OS is booted, and at block 110, the OS is started.

  FIG. 2 shows a process 200 for executing an operating system when switching between operating contexts. Process 200 continues from process 100. At block 110, the OS is started. In block 202, a trigger event, such as closing the laptop lid or pressing a hot key, switches to a different OS running a different operating context (ie, another operating context running on a different OS). It is determined whether or not to start. If it is determined that there is no switch to a different OS, the “NO” branch of block 202 is followed and flow 200 returns to block 110. In other cases, the “YES” branch of block 202 is followed, and in block 204, the OS switching flag is set. At block 206, a standby or S3 state is triggered. By triggering the S3 state, at block 208, the SMI handler is invoked or initiated (further described below in the discussion regarding FIG. 3). The SMI handler is particularly related to the detection and handling of “errors” when booting the OS.

  Performing block 110 also includes determining at block 210 whether an OS switch flag is set. Following the “NO” branch of block 210, flow 200 returns to block 110. If OS flag switching has been set, the “YES” branch of block 210 is followed and flow 200 proceeds to block 206 to trigger a standby state, ie, the S3 state.

  FIG. 3 illustrates an example process 300 for initiating a system management (mode) interrupt or SMI handler. By triggering the standby or S3 state, at block 208, the SMI handler is initiated. Process 300 may be based on an advanced configuration and power interface or ACPI standard, including blocks that invoke SMI handlers. In block 302, the S3 register is saved in the memory (ie, RAM) of the source OS, including saving context information. In contrast to the deep sleep state or S4 state, in the standby state or S3 state, the computing device can wake up and execute more quickly than the deep sleep state or S4 state. In other words, in order to enter the operating state, initialization is minimal in the standby state, ie, the S3 state, when compared to the deep sleep state, ie, the S4 state.

  In block 304, it is determined whether to switch the OS. If it is determined that the OS is not to be switched, the “NO” branch of block 304 is followed and the process continues at block 306. If the OS is to be switched, the “YES” branch of block 304 is followed, and at block 308, the OS switch context is retained or saved (discussed further below in the discussion regarding FIG. 4).

  At block 310, it is determined whether the target OS should be booted. If the target OS is not to be booted, the “NO” branch of block 310 is followed, and in block 312, automatic return of the OS is set. If the target OS is to be booted, the “YES” branch of block 310 is followed, and the target OS switching context is resumed at block 314 (discussed further below in the discussion regarding FIG. 5).

  At block 316, a jump to the resume vector of the target OS is performed (discussed further below in the discussion regarding FIG. 6). When switching context, the software code flow is efficiently started from the initial reset vector of the computing device. The BIOS code is executed and stored in a location in memory instead of executing the target OS loader (ie, the OS is efficiently loaded) as part of the normal resume code path in the standby or S3 state. A jump to an OS resumption vector that can be performed is performed. Such code can be implemented by means by which the OS returns itself from the existing standby or S3 state. This code can be executed if the BIOS tries to restore the OS again. At block 318, the target OS is executed. This can include executing a desired operational context.

  FIG. 4 shows an example of a process 400 for maintaining a switched operating system context when switching between operational contexts. Following block 308, a copy of the value in the ACPI table is saved at block 402 in accordance with the prescribed ACPI requirements. At block 404, the designated memory reserved for the source OS context is saved or retained for later use or reference. In particular implementations, a particular area in memory (ie, RAM) is specified. For example, a memory of less than “N” MB in the RAM is designated. The process 400 then returns to determining whether the target OS should be booted at block 310.

  FIG. 5 shows an example of a process 500 for resuming a target switching context when switching between operational contexts. Following block 314, in block 502, the saved standby or S3 state register is resumed. At block 504, the saved ACPI table is invoked and resumed. At block 506, the specified memory (ie, memory stored at block 404, for example) is recalled and implemented.

  FIG. 6 is an example of a process 600 that jumps to the operating system resume vector when switching between operating contexts. Process 600 may be implemented as logic within the BIOS. By using such logic, a plurality of OSs in the standby mode can be managed. The BIOS controls or determines which OS resume vector is activated. Thus, when the context is switched, the current resume vector is switched to the previous resume vector. To perform the switch, write the location of the current resume vector to temporary storage, restore the active old resume vector to the new destination OS, establish it as the current resume vector, and finally The old restart vector can be used. This can provide the ability to “ping-pong” safely back and forth between the various resume vectors without losing context. In certain implementations, a reserved memory area may be implemented to hold this data in the BIOS context. The BIOS is an entity in the computing platform that understands context switching. After block 316 where the jump to the OS resume vector is performed, block 602 performs a save of a copy of the memory area that resumes when SMM is invoked. In particular, the save performed is the old resume vector data along with any other necessary data associated with the switching source OS. This makes it possible to avoid data loss and the ability to restore and switch back in the future. In block 604, a restore of the previous memory area is performed where the previous OS resumes if not previously executed.

  The memory area used can be viewed as a private reserved memory store in the BIOS, so that each operational context efficiently has its own reserved “slot”, so there is enough space Allocated to reserve "N" contexts, eliminating the need to overwrite other operational contexts. For example, if there are two operational contexts, slot 1 of operational context 1 can exist and slot 2 of operational context 2 can exist. Therefore, when switching from the operation context 1 to the operation context 2, the active information associated with the operation context 1 can be stored in the slot # 1. Data used for the current active setting, such as the restart vector for slot # 2, can be read from slot # 2. At block 606, a bootstrap process is performed that includes replacing the memory area with code that allows jumping to an alternate OS resume vector. In particular, at block 606, the current behavior is established using the data in each private store or “slot”. Thus, a private store or “slot” can be considered a “backup” of data. Data from such a backup is programmed into actual configuration data (eg, current resume information). A command such as “mwait” can be used in the application process to set the power state. At block 608, a resume instruction is initiated to exit the SMI handler process. The SMI handler process can be initiated by various events, but in this example, the SMI handler process is initiated as defined by the ACPI S state transition that goes into the standby or S3 state that triggers the SMI. . Thus, block 602 is when entering the SMI handler and block 608 is exiting from the SMI handler. In block 610, operation continues to block 318 as described above.

BIOS Process As described above, implementations can be performed using the BIOS of the computing device. In general, the BIOS performs an operation from “power on” and hands off to the OS of the computing device. The BIOS operation can include various phases. The BIOS portion can be a unified enhanced firmware interface, ie UEFI or EFI. Pre-EFI or PEI is an early phase of computing device BIOS initialization. The driver execution environment, DXE, is performed in the second half of the BIOS initialization of the computing device. DXE is a place where the OS is started in the BIOS.

  In the standby state, that is, the S3 state, it is not necessary to perform many initializations again due to the storage in the memory (that is, the RAM), so that the OS can be resumed relatively quickly. In the standby state or S3 state, the activation can be in the PEI phase. DXE is performed when the OS is to be booted at least once and is part of each OS's complete BIOS initialization. The OS boot is performed at least once and enters a standby state, that is, an S3 state.

  Generally, when booting up in PEI in either the S3 flow or the S3 mode, it is determined whether or not the boot target OS was the previous target. For example, the S3 mode is entered from the Windows (registered trademark) OS and the process returns from the Windows (registered trademark) OS. If this case is true, the normal flow is resumed. If this is not the case, a switch to an alternative flow or OS restart vector is performed. It is determined whether another OS is activated and is in a standby state, that is, an S3 state. If the determination is not true, the process proceeds to DXE and the normal boot flow and boots the OS in DXE.

  FIG. 7 is an example of a process 700 for returning from sleep state in prior Pre-EFI or PEI when switching between operational contexts. Process 700 may be performed by a BIOS. At block 702, power on is initiated or a return from a previous BIOS flow is initiated. At block 704, it is determined whether the boot mode is resuming from the standby state, ie, the S3 state.

  If the boot mode from the standby or S3 state is not resumed, the “NO” branch of block 704 is followed, and at block 706, the non-standby or non-S3 state is executed. At block 708, it is determined whether the boot target is from the second OS or another OS. Following the “NO” branch of block 708, the existing or first OS boot flow continues. At block 712, a handoff block is set to indicate that the boot target is an existing OS or a first OS. At block 714, the BIOS process continues. Following the “YES” branch of block 708, at block 716, a non-standby state, ie, a non-S3 flow, is performed. At block 718, a handoff block is set to indicate that the boot target is the second OS or another OS. At block 714, the BIOS continues.

  If the boot mode from the standby or S3 state is resumed, the “YES” branch of block 704 is followed, and at block 720, the S3 flow continues. At block 722, it is determined whether the boot target is from a previous boot target. Following the “YES” branch of block 722, the normal resume flow continues at block 724. Following the “NO” branch of block 722, a switch to the alternate OS resume vector is performed. At block 728, it is determined whether the OS has been booted from the standby state, ie, the S3 state. Following the “NO” branch of block 728, block 708 is executed. Following the “YES” branch at 728, at block 730, the context is saved and jumps to an alternate OS resume vector.

  FIG. 8 is an example of a process 800 for returning from a sleep state in DXE when switching between operation contexts. Process 800 may be performed by a BIOS. At block 802, a boot option flow is executed. At block 804, it is determined whether the OS switch BIOS option is enabled. Following the “NO” branch of block 804, it is determined in block 806 whether the handoff block from the PEI phase indicates a switch. Following the “YES” branch of block 806, at block 808, the boot option is changed to point to the memory store containing the alternate OS. Following the “NO” branch of block 806, at block 810, the BIOS process continues. If the OS switch BIOS option is enabled, follow the “YES” branch of block 804 and code is applied that disables the start hotkey or start applet that triggered the call to the operational context. At block 810, the BIOS process continues.

Example Computing Device FIG. 9 illustrates an example computing device 900 that performs operational context switching. As described above, computing device 900 may include a variety of devices such as tablets, laptop computers, and the like.

  Computing device 900 includes a processor 902 that is one or more processors. The processor 902 can be one processing unit or several processing units, all of which can include one or more computing units or multiple cores. The processor 902 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operational instructions. can do. Among other functions, the processor 902 can be configured to fetch and execute computer-readable instructions or processor-accessible instructions stored in the memory 904 or other computer-readable storage medium.

  The memory 904 is an example of a computer-readable storage medium that stores instructions. The instructions, when executed by the processor 902, cause the processor 902 to perform the various functions described above. For example, the memory 904 can generally include both volatile and non-volatile memory (eg, RAM, ROM, etc.). Memory 904 may be referred to herein as memory or a computer readable storage medium. The memory 904 can store computer-readable processor-executable program instructions as computer program code, the computer program code configured to perform the operations and functions described in the embodiments herein. As a particular machine to be executed by the processor 902.

  The memory 904 can include one or more operating systems 906 and can store one or more applications 908. The operating system 906 can be one of a variety of known and future operating systems implemented on personal computers, audiovisual devices, and the like. Applications 908 can include preconfigured / installed applications and downloadable applications. In addition, memory 904 can include data 910. Operating system 906 and application 908 can define operational contexts as described above.

  The memory 904 specifically includes random access memory or RAM 912, in which the process stores information while in the standby state, ie, the S3 state. Further, the BIOS 914 is included in the memory 904. The BIOS 914 can be stored in a read only memory (ROM).

  Computing device 900 includes a memory controller 916. While in the standby state, that is, the S3 state, the memory controller 916 can be used to execute operations in the memory. The RAM 912 can be kept in a self-refresh mode so that the RAM 912 can maintain a minimal context that keeps the computing device alive. Thus, the memory is waiting when the processor 902 and other devices of the computing device wake up. Thereby, the standby state, that is, the S3 state can be a low power consumption state as compared with the case where the application 908 is being executed.

  The computing device can further include an input / output device 918 that is connected to various internal devices, external devices, and peripherals, such as a monitor, keyboard, pointing device, and the like. Various known and future interfaces can be included in the input / output device 918. In particular, the input / output device 918 can provide access to pre-installed or user-programmed hot keys that can initiate a transition to an existing operating context or a different operating context.

  The example computing device 900 described herein is just one example that is suitable for some implementations, and is an environment, architecture, and architecture that can implement the processes, components, and features described herein. It is not intended to suggest any limitation as to the scope of use or functionality of the framework.

  In general, any functionality described with reference to the figures can be implemented using software, hardware (eg, fixed logic circuitry), or a combination of these implementations. The program code may be stored in one or more computer readable memory devices or other computer readable storage devices. Accordingly, the processes and components described herein can be implemented by a computer program product.

  As described above, a computer storage medium is a volatile medium, non-volatile medium, removable medium implemented in any method or technique for storing information such as computer readable instructions, data structures, program modules, or other data. And non-removable media. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage device, magnetic cassette, magnetic tape, magnetic disk It includes storage devices, or other magnetic storage devices, or any other medium that can be used to store information for access by a computing device.

Memory Allocation Example Referring to FIG. 10, RAM 912 can allocate sections or have reserved sections for the information / data described above with respect to the process. TSEG 1000 is a segment in memory that the SMM defines for initialization of the CPU or processor 902. TSEG 1000 includes SMM code and logic associated with the SMM. The reserved OS switching context 1002 is an area reserved as BIOS overhead to achieve additional storage and restoration of information associated with a plurality of operation contexts that can be a switching destination or a switching source. . The OS1 memory page 1004 and the OS2 memory page 1006 are specific OS sections. It should be understood that other OSes may be implemented and sections in RAM 912 may be reserved for such OSs. The compatible address range 1010 is an address for accessing a specific OS. The section (s) of RAM 912 can be reserved in other data and information 1008 related to switching of operating contexts. The remaining RAM 1012 shows a section of RAM 912 that is not used for the described process.

  An implementation according to the invention has been described in the context of a particular embodiment. These embodiments are meant to be illustrative and not limiting. Many variations, modifications, additions and improvements are possible. Thus, multiple instances can be provided for components described herein as a single instance. The boundaries between the various components, operations, and data stores are somewhat arbitrary, and specific operations are shown in the context of certain exemplary configurations. Other allocations of functions are contemplated and can be within the scope of the following claims. Finally, structures and functions presented as discrete components in various configurations can also be implemented as a combined structure or component. These and other variations, modifications, additions and improvements can be within the scope of the invention as defined in the following claims.

Claims (20)

A method for switching operation contexts,
Under the control of one or more processors configured with executable instructions,
Putting the computing device into a standby power state;
Determining one of a plurality of operating systems to boot from the standby power state;
Activating from the standby power state a desired operational context to be executed in the determined operating system;
Including a method.   The method of claim 1, wherein determining one of the plurality of operating systems is based on user behavior at the computing device.   3. A method according to claim 1 or claim 2, wherein the determining comprises switching from a previous operating system to a different operating system.   4. The method according to claim 1, wherein booting from the standby power state includes detecting an error when booting up an operating system and booting up the determined operating system. 5. The method according to one.   The method according to any one of claims 1 to 4, wherein the step of entering the standby power state, the step of determining and the step of starting are independent of a platform and an operating system.   6. The method of any one of claims 1-5, further comprising storing data in a memory to perform the activation.   7. The method according to any one of claims 1 to 6, further comprising reserving data memory for booting the plurality of operating systems. A computing device,
One or more processors;
A memory controller configured for the one or more processors;
A memory configured for the one or more processors and the memory controller;
The memory includes one or more operating systems such that an operating system that supports a desired operating context is booted from the standby power state when the computing device is in a standby power state. device.   The computing device of claim 8, wherein the memory controller performs operations from memory while the computing device is in a standby power state.   10. The computing device of claim 8 or claim 9, wherein the memory includes random access memory, the random access memory being allocated for booting the one or more operating systems from a standby power state.   10. The computing device of claim 8 or claim 9, wherein the memory includes random access memory, and data for booting the one or more operating systems from a standby power state is stored in the random access memory.   12. The memory according to any one of claims 8 to 11, wherein the memory includes system management code that detects an error when booting an operating system and launches the operating system appropriate for a desired operating context. Computing device.   13. The computing device according to any one of claims 8 to 12, further comprising an input / output interface connected to the device and peripheral devices to initiate activation of an operational context.   14. A computing device according to any one of claims 8 to 13, further comprising a basic input / output system (BIOS) that supports the standby power state, wherein the desired operating system is booted.   15. The computing device of claim 14, wherein the BIOS includes various phases from which the desired operating system is booted. Putting the computing device into a standby power state;
Storing in memory a data location for booting one or more operating systems that support multiple operating contexts from the standby power state;
Activating an operating system supporting a desired operating context from the standby power state;
For causing the computing device to execute the program.   The program of claim 16, wherein placing the computing device into a standby power state and activating the operating system are based on user behavior on the computing device.   18. A program according to claim 16 or claim 17, wherein storing the data location in memory comprises storing data from a previously implemented operating system.   The program according to any one of claims 16 to 18, wherein the step of starting includes reading from a storage memory allocated for booting the one or more operating systems.   20. The computer device according to any one of claims 16 to 19, further causing the computing device to perform a step of identifying a system error when booting up the operating system and a step of starting another operating system. Program.

Images