Title of Invention

SYSTEM AND METHOD TO MANAGE MULTIPLE OPERATING SYSTEMS

Abstract

This invention explains a method and a system to manage multiple operating systems wherein the said method comprises the steps of: selecting the OS to be booted from a plurality of OS by the selector component; switching to a different OS or to suspend the hardware by a switcher component; partitioning the system RAM to each of the OS instances; loading multiple operating systems into the memory without disturbing the state of the previously loaded operating systems; performing the OS sleep routine on reception of the sleep signal; and performing the resume procedure on reception of the resume signal.

Full Text

FIELD OF INVENTION The present invention relates to operating systems and further, to a method to multi-boot a device (utilizing a single processor for all the OS instances) and switch between the loaded operating systems dynamically. More particularly this invention relates to a system and method to manage multiple operating systems. DESCRIPTION OF THE RELATED ART Figure 2 illustrates the block diagram of a typical computing device. It essentially consists of a Processor [3202], a System RAM (Random Access Memory) [3207], a ROM (Read Only Memory) [3201] and a Host Bus [3203] to communicate between the various components. Optionally, it can have some Non-volatile storage and other peripherals [3205, 3206] which are either directly connected to the Host Bus or to a separate Peripheral Bus [3204]. In this discussion, we are mentioning the device as a single processor system, though the same procedure will hold good for a device where multiple processors are present but only one is utilized for running the OS (eg. asymmetric multiprocessor systems). The ROM contains the software for the processor to run, which could be either the whole operating system or a bootloader which loads the main operating system from another ROM area or a non-volatile storage into the system memory and executes it. Figure 3 illustrates the software components of a typical computing system and the interaction between them. There is a Bootloader [3301] whose job is to load the operating system into system RAM and execute it. The Operating System (OS) [3302] is the main controlling software and manages the input/output and functioning of the system. There is another component BSP (Board Support Package) [3303] which interfaces between the hardware and the software components of the OS. Its functionality is to provide an abstraction layer to the OS so as to enable to run on a particular device and control it. BSP consists basically of hardware drivers [3305] which are software components to deal directly with the hardware and harness their functionality. OS and BSP both have Power Management [3304, 3306] modules, which together control the power management of the system. These components are responsible to save the state of the system and then put it to power-saving (or sleep) mode and restore it to the saved state when desired. The operating system's power management module takes care of software components which in turn uses BSP's power management module to control the hardware components in the system. Figure 1 illustrates the state diagram of a typical system. On power-on or reset, the device comes into the Powered state [3102]. On entering the powered state the processor [3202] will start executing the code stored in ROM [3201], which after the basic initialization of the hardware jump to the bootloader [3301] code. The bootloader will then load the operating system from either ROM, a non-volatile storage [3208] or I/O peripheral [3205/3206] into the System RAM [3207] and execute it. This process will finish with OS successfully running on the device and system is said to be in Running [3103] state. This flow is summarized in figure 4(a). On receipt of a Sleep signal, which could be a system generated event or user input, the OS starts its sleep procedure. The sleep procedure is a part of OS Power Management [3306] module which in-turn uses the services provided by the BSP Power Management [3304] module. This sequence is illustrated in flowchart 4(b). On completion of the sleep procedure the device is said to be in Suspended [3104] state. The Wakeup procedure, as illustrated in figure 4(c) starts with the Resume or Wakeup signal. It is a part of the power management modules of OS and BSP; on completion it puts the device again into the Running [3103] state. The current systems are built with the view that only a single instance of the operating system is present in the memory, i.e. a single instance of operating system is loaded on the device. A loaded instance continues to run until the system is reset, in which case the existing instance gets unloaded. On boot-up, a fresh instance of the same or a different operating system could be loaded. This methodology leaves no scope for two or more instances to be loaded simultaneously onto a single processor, let alone switching between them. Furthermore, we can't change much in the existing operating systems or device hardware to incorporate multi-loading as it would be a costly affair. SUMMARY OF THE INVENTION The primary object of the present invention is therefore to load several instances of operating systems on a device, utilizing a single processor, execute them one at a time and switch between them dynamically upon user request or a system generated event. It is another object of this invention to achieve the same with limited modifications to the existing hardware and to the existing operating systems. It is another object of this invention not to include the steps and standards required for compatible working of various peripherals with different operating systems on the device. The present invention describes a method to manage multiple operating systems loaded on a device, utilizing a single processor, simultaneously. It enables a device to boot-up multiple operating systems on a device without unloading the previously loaded OS. It further describes a method to switch between the loaded operating systems dynamically on user input or otherwise. This functionality is achieved with no modifications to the hardware of the existing devices. Though some modifications are suggested in this proposal for enhanced performance, they are not mandatory. When a device supporting power-save goes into sleep mode it saves its state in system memory and then switches off most of its devices, which on wakeup are reinitialized and restored to the previous state. Exploiting this behavior, the present invention proposes to sleep the running OS and load or wakeup another OS instead of the one previously running. This enables us to either load another OS onto the device or switch to a previously loaded OS without unloading the currently running one. Accordingly, the present invention explains a method to manage multiple operating systems, the said method comprising the steps of: (a) selecting the OS to be booted from a plurality of OS or switched onto the system based upon OSSelection and OSLoaded flags by the selector component; (b) switching to a different OS or to suspend the hardware based upon OSSwitch flag by a switcher component; (c) partitioning the system RAM to each of the OS instances; (d) loading multiple operating systems into the memory without disturbing the state of the previously loaded operating systems; (e) performing the OS sleep routine on reception of the sleep signal; and (f) performing the resume procedure on reception of the resume signal. Accordingly, the present invention further explains a system to manage multiple operating systems, the said system comprising: (a) means for selecting the OS to be booted from a plurality of OS or switched onto the system based upon OSSelection and OSLoaded flags by the selector component; (b) means for switching to a different OS or to suspend the hardware based upon OSSwitch flag by a switcher component; (c) means for partitioning the system RAM to each of the OS instances; (d) means for loading multiple operating systems into the memory without disturbing the state of the previously loaded operating systems; (e) means for performing the OS sleep routine on reception of the sleep signal; and (f) means for performing the resume procedure on reception of the resume signal. The other objects, features and advantages of the present invention will be apparent from the detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS Figure 1 illustrates the present scenario. Figure 2 illustrates the block diagram of the apparatus. Figure 3 illustrates the software components of the related art. Figure 4 illustrates the Flowchart of the related art. Figure 5 illustrates the state transition diagram of the proposed system. Figure 6 illustrates the boot-up sequence of the proposed device on power-on or reset. Figure 7 is an illustration of the proposed switch sequence. Figure 8 is a diagram illustrating the sleep sequence of the proposed device. Figure 9 illustrates the proposed resume sequence of the device. Figure 10 illustrates the software components of the proposed system. DETAILED DESCRIPTION OF THE INVENTION A preferred embodiment of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiment is merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. The proposed system runs on the apparatus as described in Figure 2. There are some modifications suggested below (Modification to the apparatus). Figure 10 illustrates the components of the proposed system. The new components added in the proposed device, as compared to the prior art, are Selector [5607] and Switcher [5608]. There are following additions when viewed in comparison with the components described above in structure of the related art. Selector [5607]: This component is added to the Bootloader and it selects the OS to be booted or switched onto the system based upon OSSelection and OSLoaded flags. Switcher [5608]: This component is a modification to BSP, specifically the Power Management component. It decides whether to switch to a different OS or to suspend the hardware based upon OSSwitch flag. The functionality of these modules are described in operation of the invention. Modifications to the apparatus The suggested modifications to the apparatus described in Structure of the related art are described below: 1. There should be support for the individual partitions of the system RAM to be put to power-saving mode, so that the part of RAM which is not being used could be put in low-power state. 2. There should be enough sleep-persistent registers available to store all the flags required in the described procedure. Partitioning of system RAM In software, the system RAM has to be partitioned for each of the OS instances. In partitioning, what is meant is that, the available physical RAM has to be judiciously allotted to the different OS instances. The methodology to be followed for partitioning is implementation specific. Physically the RAM could be same or it could exist in different banks accessible to the processor. GUI / Application considerations The provisions to switch between the various installed operating systems have to be provided by an application / GUI as required by the system. The construction of such an application / GUI is outside the scope of this invention proposal. Operation Figure 5 shows the state chart of the proposed system. It shows two instances of operating system, X and Y, loaded onto the device and the state-transitions that happen between them. The block arrow [5101] shows the state-transitions while switching between a loaded OS instance X to another loaded OS instance Y. In contrast with figure 1, the device has two separate Running states [5103, 5105] each belonging to a different instance of operating system. The device will have Bootup, Reset, Sleep and Wakeup transitions similar to the device operation explained in operation of the related art. Along with this, the device will switch its state from one running operating system to another running operating system as shown in the diagram [5106]. Though the diagram shows only two OS instances, the device can have several of them. Each of the system transitions and the procedure associated with them are explained with the help of accompanied flowcharts in the following sub-sections: Bootup The modified boot-up sequence of device is shown in figure 6. This procedure includes the method to load multiple operating systems in the memory without disturbing the state of the previously loaded operating systems. This process starts when the user selects to switch on the device or reset it. On Power-On or Reset the device starts with the execution of Bootloader [5601]. The bootloader invokes the Selector [5607] component, which performs the steps [5203], [5204], and then continues with the loading [5207] and execution [5208] of operating system. Upon completion of OS bootup the OSLoaded flag is updated to reflect successful booting. Switch The procedure to switch from one OS to another is illustrated in figure 7 This diagram also incorporates the scenario in which the OS to be switched to is not loaded, in which case the boot-up sequence is followed as shown [5310]. This diagram should be viewed in conjunction with figure 6.. The flow starts on a Switch signal [5301], which could either be a system generated event or a user request. On the switch signal, the OSSelection flag is updated to reflect the OS to be loaded and the OSSwitch flag is set to True. This indicates that switch procedure is taking place. Now the standard OS sleep routine is called [5304] which towards the end of its completion calls the BSP power management component [5604]. In here, Switcher [5608] takes control and performs the steps [5305] to [5308] based upon the OSSwitch flag. If OSSwitch is set to False, then the hardware is put to sleep. This check is present here to facilitate the Sleep procedure explained below (SLEEP). If the system is undergoing OS switching, step [5308] is performed and if the selected OS is already loaded to the system, it is woken-up and put to running state as illustrated in steps [5311] to [5313]. But if the OS is not already loaded [5309], this is identified by OSLoaded flag, the Switcher module branches to the Bootloader [5310] - [5206] and loads the OS and boots it onto the system. Sleep Figure 8 illustrates the sleep sequence of the proposed system. On receipt of the Sleep signal [5401], which could be a system event or a user request, the OSSelection flag is updated [5402] to the current OS and the OSSwitch flag is cleared [5403] to specify that the OS is undergoing sleep and not switch. The sleep procedure then branches to the Switcher module [5404] - [5303], where the OS Sleep routine is called [5304] and then hardware is put to sleep [5306] as the OSSwitch flag is cleared. With this the sleep procedure is complete [5307]. Resume Figure 9 illustrates the resume procedure of the proposed system. The flow starts on receiving the Resume Signal [5501], which could be a system generated event or a user request, upon which the hardware automatically comes alive and the execution starts from the Bootloader. The bootloader identifies that hardware has come alive from sleep by reading hardware register values which is hardware specific and varies from system to system. On resume, the bootloader will do the necessary hardware initialization and then pass the control to Selector [5607] which reads the OSSelection earlier updated in step [5402] in sleep procedure. The OSLoaded flag is verified to be True [5503] and the OS wakeup routine is invoked [5505]. Upon completion the OSSelection and OSSwitch flags are cleared [5506] and this completes the wakeup procedure. If the OSLoaded flag is False, as identified in step [5503], the OS is loaded and booted onto the device [5504] - [5206]; if it is true the process described above is followed. Step [5508] is present in the procedure to facilitate switching to another OS instance when a previous instance is put to sleep mode. The proposed invention overcomes the limitation of the current systems in managing multiple operating systems. It enables a device to load multiple operating systems at the same time and to switch between the loaded operating systems on a user action or a system event. The devices having multi-boot capability can now provide a way to switch between the operating systems, which will consume less time than unloading the current operating system and loading another one and will be more user friendly as the state of running OS is saved. This is achieved with virtually no modifications to the existing hardware or the operating systems, which means that there will not be any compatibility issues with the present devices or the systems. The proposed system is also cheap in terms of resources consumed, adding only a negligible size to the system footprint and a small overhead in operation. COMMERCIAL IMPORTANCE The proposed invention can provide a new feature to devices like mobile phones and PDAs, where they will come with an option of choosing among the various deployed operating systems. The user will have the flexibility of running the OS he requires for the job, a flexibility which currently is available only with a full-fledged computer. This was earlier not possible because loading another OS required reboot, upon which the loaded OS loses its state. This will be a unique product in the market and the company can expect a gain in market share of such devices. With the proposed system, the devices can switch operating systems on a need basis to cater to the current job-in-hand more efficiently. For example, a multi-function device while playing a DVD movie can run on one OS and while providing a more user interactive feature like Web browsing can run on another. Further, the potential of this invention could be harnessed with the multi-function devices as suggested above. Also, there could be desktops and laptops featuring switching of operating systems where a user need not reboot to load a different OS; he can simply switch between the loaded operating systems without losing their state. Such a computer would definitely have a competitive edge in market amongst others. It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a computer, mobile communication device, mobile server or a multi function device. Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart there from. GLOSSARY OF TERMS AND THEIR DEFINITIONS Instance of operating system An occurrence of the operating system which could be loaded into system memory and executed independent of other instances is known as an instance of operating system. Non-volatile storage Storage space which retains its contents when device is powered off is termed as non-volatile storage. Sleep persistent Resources which remain accessible and retain their state during sleep and sleep-wakeup transitions are termed sleep persistent. Boot The procedure to load an operating system into memory, initialize and execute it is known as booting. This definition refers to the standard definition of booting of an OS. Switch The procedure to migrate the control from one operating system to another operating system loaded in memory is known as switching. Flags OSSelection This flag contains the unique identifier to an instance of the operating systems installed / deployed on the system. This flag should be sleep-persistent. OSLoaded This flag identifies if the particular instance of operating system has already been loaded on the system. This flag should be sleep-persistent. OSSwitch This flag indicates if the system is undergoing switching of operating system instances. OSLoadAddress This is the physical memory location to which an OS has to be loaded. This value is looked up from a pre-configured hash table, which is a part of the Selector [5607] component. WE CLAIM 1. A method to manage multiple operating systems, the said method comprising the steps of: (a) selecting the OS to be booted from a plurality of OS or switched onto the system based upon OSSelection and OSLoaded flags by the selector component; (b) switching to a different OS or to suspend the hardware based upon OSSwitch flag by a switcher component; (c) partitioning the system RAM to each of the OS instances; (d) loading multiple operating systems into the memory without disturbing the state of the previously loaded operating systems; (e) performing the OS sleep routine on reception of the sleep signal; and (f) performing the resume procedure on reception of the resume signal. 2. A method as claimed in claim 1 wherein the selector component is added to the Bootloader. 3. A method as claimed in claim 1 wherein the switcher component is a Power Management component. 4. A method as claimed in claim 1 wherein the unused RAM is put in low-power state by putting the individual partitions of the system RAM to power-saving mode. 5. A method as claimed in claim 1 wherein sleep-persistent registers are provided to store all flags. 6. A method as claimed in claim 1 wherein partitioning the system RAM to each of the OS instances makes the available physical RAM judiciously allotted to the different OS instances. 7. A method as claimed in claim 1 wherein physically the RAM is same or it exist in different banks accessible to the processor. 8. A method as claimed in claim 1 wherein switching between the various installed operating systems is provided by an application / GUI. 9. A method as claimed in claim 1 wherein the loading/booting process starts when the user selects to switch on the device or reset it. 10. A method as claimed in claim 9 wherein on Power-On or Reset the device starts with the execution of Bootloader which invokes the selector component. 11. A method as claimed in claim 9 wherein upon completion of OS bootup the OSLoaded flag is updated to indicate successful booting. 12. A method as claimed in claim 1 wherein for switching the switch signal is either a system generated event or a user request. 13. A method as claimed in claim 1 wherein on switching, the OSSelection flag is updated to reflect the OS to be loaded and the OSSwitch flag is set to True. 14. A method as claimed in claim 1 wherein the sleep signal is either a system generated event or a user request. 15. A method as claimed in claim 1 wherein on receipt of the Sleep signal the OSSelection flag is updated to the current OS and the OSSwitch flag is cleared to specify that the OS is undergoing sleep. 16. A method as claimed in claim 1 wherein in the sleep procedure the OS Sleep routine is called and the hardware is put to sleep as the OSSwitch flag is cleared. 17. A method as claimed in claim 1 wherein the resume signal is either a system generated event or a user request. 18. A method as claimed in claim 1 wherein on receiving the Resume Signal the hardware automatically comes alive and the execution starts from the Bootloader. 19. A method as claimed in claim 18 wherein the bootloader identifies the hardware which came alive from sleep by reading hardware register values. 20. A method as claimed in claim 18 wherein on resume, the bootloader does the hardware initialization and pass the control to Selector which reads the OSSelection. 21. A method as claimed in claim 18 wherein the OSLoaded flag is verified to be True and the OS wakeup routine is invoked. 22. A method as claimed in claim 18 wherein upon completion of the wakeup procedure OSSelection and OSSwitch flags are cleared. 23. A system to manage multiple operating systems, the said system comprising: (a) means for selecting the OS to be booted from a plurality of OS or switched onto the system based upon OSSelection and OSLoaded flags by the selector component; (b) means for switching to a different OS or to suspend the hardware based upon OSSwitch flag by a switcher component; (c) means for partitioning the system RAM to each of the OS instances; (d) means for loading multiple operating systems into the memory without disturbing the state of the previously loaded operating systems; (e) means for performing the OS sleep routine on reception of the sleep signal; and (f) means for performing the resume procedure on reception of the resume signal. .A method to manage multiple operating systems substantially as herein described particularly with reference to the accompanying drawings. .A system to manage multiple operating systems substantially as herein described particularly with reference to the accompanying drawings. Dated this 18th day of April 2005

Documents:

1493-che-2004 abstract-duplicate.pdf

1493-che-2004 claims-duplicate.pdf

1493-che-2004 description (complete)-duplicate.pdf

1493-che-2004 drawings-duplicate.pdf

1493-che-2004 form 1.pdf

1493-che-2004 form 5.pdf

1493-che-2004 power of attorney.pdf

1493-che-2004-abstract.pdf

1493-che-2004-claims.pdf

1493-che-2004-correspondnece-others.pdf

1493-che-2004-correspondnece-po.pdf

1493-che-2004-description(complete).pdf

1493-che-2004-description(provisional).pdf

1493-che-2004-drawings.pdf

1493-che-2004-form 1.pdf

1493-che-2004-form 26.pdf

1493-che-2004-form 9.pdf