Adaptively storing system code in non-volatile storage

1

ADAPTIVELY STORING SYSTEM CODE IN NON-VOLATILE STORAGE

BACKGROUND

This invention relates generally to storage and update of the operating system code, and more particularly, to storage and update of an image of system code in non-volatile storage.

Non-volatile storage may be well suited to long term storage of code and data in some cases. As one example, in a mobile network device, a non-volatile memory may store operating system code that may include the operating system, drivers, and applications. Using a software application, an original image of the operating system code may be installed within a non-volatile memory array in the fonn of an object. Often the operating system, drivers, and applications are combined into a single, large monolithic object. Before storing or installing the original image in a non-volatile storage, non-volatile file systems combine the operating system, drivers, and applications into a compiled image. Compiling may be used to link the operating system code into the single, large monolithic object that is installed as one code component for that image.

However, such a large monolithic object can only be updated or changed as a whole. Flash memory file systems use a code manager to modify or update a driver, an application, or the operating system of an original compiled image (e.g., original equipment manufacturer (OEM) image) stored as a relatively large single unit of the operating system code. For embedded systems, use of one large single object including the operating system, drivers and applications fails to provide the flexibility to update sections of the operating system code, as the entire image may need to be replaced, consuming a significant amount of time. Thus, operating system or driver patching, updates and addition of code to a system may not be feasible. Moreover, memory read and program performance varies significantly between different types of flash memories used to store the operating system code. For example, it takes a relatively longer time to access data from one type of flash memory than is the case with other types of flash memories. Also, without re-writing the entire image, tuning of the system based on an individual’ s usage of the device may not be supported.

Thus, there is a continuing need for altemate ways to store and update the system code, especially an image of operating system code in non-volatile storage.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a depiction of a system including a non-volatile storage consistent with one embodiment of the present invention;

FIG. 2 is a flow chart for a code manager that installs and manages an image of operating system code in accordance with one embodiment of the invention;

FIG. 3 is a flow chart for a kemel program which enables adaptive storage and update of the operating system code according to one embodiment of the present invention;

FIG. 4 is a flow chart for a code profiler that monitors the operating system code installed in the system shown in FIG. 1 according to one embodiment of the present invention;

FIG. 5 is a schematic depiction of one embodiment of the present invention;

FIG. 6 is a schematic depiction of a non-volatile memory according to an embodiment of the present invention; and

2

FIG. 7 is a flow chart consistent with one embodiment of the present invention.

DETAILED DESCRIPTION

Referring to FIG. 1, a system 10 may include a processor 20, coupled through an interface 25, to a system memory 30 and a non-volatile storage device 35 in accordance with one embodiment of the present invention. The interface 25 may couple a communication interface 40 and a user interface 45 to the processor 20. The system 10 may be any processorbased system that uses the non-volatile storage device 35 for adaptively storing and updating of code and/or data. In one embodiment, the non-volatile storage device 35 may store an original image of operating system code 48 into at least two code portions, code portion 50 and code portion 52, both of which are separately accessible. In another embodiment, segmentation of code other than the operating system code 48 may be possible. For instance, a portion of the operating system may be swapped out for an application that is used more frequently.

In one embodiment, the system 10 may adaptively adjust the storage of the original image of the operating system code 48 across the non-volatile storage device 35. The operating system code 48 may include an operating system 55, drivers 60 for operating the system 10 hardware, and applications 65 that run on the operating system 55. The code portions 50 and 52 may be movably stored within the non-volatile storage device 35.As executables, the code portions 50 and 52 may be selectively replaced, partially updating the original image of the operating system code 48. In this way, rather than combining the operating system 55, drivers 60 and the applications 65 into a single monolithic code component, which is then installed in a non-volatile memory, the system 10 may support operating system patching or driver updates, and adding of additional code to the operating system code 48. As a result, the system 10 may be tuned to support the individual’s usage of the operating system code 48 without having to re-write the entire image.

An embedded system is any non-personal computer system or computing device that perfonns a dedicated function or is designed for use with a specific embedded software application. The system 10 may be an embedded system capable of computing and/ or communication for a mobile or a battery-powered portable system, a cellular or mobile phone, a personal digital assistant (PDA), or a wireless access device, to mention a few examples. In a closed enviromnent, such as an embedded system or in a real time operating system (RTOS), the operating system 55 may run different devices, including a personal digital assistant or a tablet using the original image of the operating system code 48 consistent with one embodiment. An embedded system may be singlefunction or task-specific devices in which the operating system 55 and applications 65 are customized and then “locked down” before deployment, closing the embedded systems for any modification from an end user. Examples of some embedded systems include information kiosks, cash registers, automatic teller machines (ATMs), industrial controllers, server appliances, medical monitors, set top boxes, advanced consumer electronics, and handheld devices. Embedded operating systems are usually highly customized for a specific function and may be optimized for special hardware or a specific application in many situations. The scope of the present invention is not limited to embedded systems since other systems capable of storing a volatile memory state are well within the scope and spirit of different embodiments of the present invention.