GB2452735A

GB2452735A - Loading and executing programs in parallel during boot loading

Info

Publication number: GB2452735A
Application number: GB0717788A
Authority: GB
Inventors: Steven Rawlings
Original assignee: Symbian Software Ltd
Current assignee: Symbian Software Ltd
Priority date: 2007-09-12
Filing date: 2007-09-12
Publication date: 2009-03-18
Also published as: WO2009034316A3; GB0717788D0; WO2009034316A2

Abstract

In a start-up process of a device, such as a smartphone or laptop, a boot application (10), stored in non-volatile flash memory (4), is loaded into working RAM (3) and executed by CPU (1). The boot application causes a series of other programs (11) to be loaded and run. The boot application also defines the order in which programs (11) will be loaded into RAM and the order in which they will be executed. The boot application loads at least one program needed for the start-up process, e.g. program B, whilst another program on which it depends, e.g. program A, is being executed. Thus, for example, program B will be fully loaded into RAM by the time program A has completed. This separation of the order in which programs are loaded into working memory from the order in which the programs are executed can result in shorter start-up times. CPU (1) may be capable of multithreaded operation.

Description

BOOT LOADING

This invention relates to putting data processing devices in a ready condition, for example during a boot sequence.

A data processing device typically comprises a data processing unit, such as a CPU (central processing unit), working memory such as RAM (random access memory) that holds the current state of the device and non-volatile memory such as flash memory or a hard disc that stores program code.

Normally the CPU does not execute programs directly from the non-volatile memory, because it is quicker for the program code to be loaded into the working memory first and executed from there. In addition, the RAM may hold other state data such as the contents of variables or other data that is being processed by the device.

In order for the device to perform a particular function the content of the working memory must first be configured accordingly. This configuration needs to take place when the device is initially turned on with the working memory initially empty, and when the functionality of the device needs to be changed -for example by making an additional program ready for use. It may also be necessary for the working memory to be configured, or reconfigured, during the execution of a program, for example in demand paging environments.

One option for configuring the required memory content is to load it as a bit-for-bit image from the non-volatile memory. Another option is for the data processing unit to execute one or more programs that generate the required content. The former method is typically relatively quick, but is inflexible. The memory content that is required might need to be different depending on the hardware capabilities of the device, and the pre-stored image might not be suitable for a device's current hardware configurat,on. For that reason, the former method can only be used in a limited set of situations, such as when the device has only one possible hardware state or when a device is resuming operation from a hibernation mode. Configuring the working memory by executing one or more programs allows the configuration to accommodate different hardware configurations, which means that the designer of the program can write a single set of code to set up a range of devices. However, it takes some time for the program(s) to execute, with the result that a device that uses this method might be perceived as being slow to adopt a desired configuration. This is particularly significant when the device is started from cold, when the working memory is initially empty and a considerable amount of code may need to be executed in order to put the working memory in the desired state.

When a device is booted from cold, it initially performs a set of operations defined by its hardware. Those instructions typically perform hardware checks and then cause the device to look in a particular area of its non-volatile program memory for a boot loader program, and to execute that program. The remainder of the boot sequence is then performed under the control of the boot loader program. The boot loader program may then cause one or more other subsidiary programs to be executed in order to configure the device as required. Those subsidiary programs may be interdependent.

For example, if the device has components that are connected to the CPU over an internal bus then a driver that allows the CPU to communicate over that bus might need to be operational before a driver for the other components that are connected to the bus can be set up. Therefore, the boot loader program normally has a set order in which the subsidiary programs are to be run. When one of the programs has finished executing, or has reached the stage where the next program in the list can safely be run, that next program is loaded from non-volatile memory into working memory and then executed.

It is desirable to reduce the start-up time of devices such as laptops and smariphones. There is therefore a need for a quicker start-up process.

According to a first aspect of the present invention there is provided a data processing device having a working memory from which it can execute program code and a non-volatile memory for storing program code including code defining at least two programs that are executable to configure the device for operation, the device being arranged to perform a pre-defined sequence of operations in order to place itself in a ready state, the sequence comprising: loading the code for one of the programs into working memory of the processing device; executing that code from the working memory; and whilst that program is executing and before it has reached a state at which a second one of the programs can successfully be executed, loading the code for the second one of the programs into the working memory.

The non-volatile memory may store code defining a configuration control program, the configuration control program being executable by the device to cause it to perform the said pre-defined sequence of operations.

The device is preferably arranged to execute the configuration control program automatically when the device is started up. The device may additionally or alternatively be arranged to execute the configuration control program automatically when an application is initiated on the device. The device may also be arranged to execute the configuration control program automatically when an item of hardware is attached to the device.

The device preferably comprises a data processor for executing the programs. The data processor is preferably capable of executing two or more processes in parallel, whereby the code for the second one of the programs can be loaded into working memory by a first thread whilst the first one of the programs is executing as a second thread. The first one of the programs may communicate during its execution with a peripheral hardware component of the device.

The device could be arranged to load the code for the second one of the programs into the working memory at least during periods when execution of the first one of the programs is temporarily blocked.

According to a second aspect of the invention there is provided a method for placing in a ready state a data processing device having a working memory from which it can execute program code and a non-volatile memory for storing program code including code defining at least two programs that are executable to configure the device tor operation, the method comprising performing a pre-defined sequence of operations comprising: loading the code for one of the programs into working memory of the processing device; executing that code from the working memory; and whilst that program is executing and before it has reached a state at which a second one of the programs can successfully be executed, loading the code for the second one of the programs into the working memory.

According to a third aspect of the invention there is provided a computer program for placing in a ready state a data processing device having a working memory from which it can execute program code and a non-volatile memory for storing program code including code defining at least two programs that are executable to configure the device for operation, the said computer program comprising instructions for causing the device to perform a pre-defined sequence of operations comprising: loading the code for one of the programs into working memory of the processing device; executing that code from the working memory; and whilst that program is executing and before it has reached a state at which a second one of the programs can successfully be executed, loading the code for the second one of the programs into the working memory.

According to a fourth aspect of the nvention there is provided a data carrier storing a computer program as defined above.

The present Invention will now be described by way of example with reference to the accompanying drawings. In the drawings: Figure 1 is a block diagram of a smartphone; and Figure 2 is a timing diagram illustrating steps in a boot-up process.

The example described below is of a smartphone. In the start-up process of the smartphone described one program that is needed for the start-up process can be loaded into memory whilst another process is being executed.

This separation of the order in which programs are loaded into working memory from the order in which the programs are executed can result in shorter start-up times. Embodiments of the Invention can therefore enable more efficient use of the hardware resources of a device. The CPU can be usefully employed for a greater proportion of time. In a preferred embodiment the memory is handled in a novel way, with the aim that program code or associated data is pre-loaded into the memory by the time the CPU is available to execute the program. This can offer improved performance of a device.

The smartphone shown in figure 1 comprises a CPU 1 which can communicate over a bus 2 with volatile RAM memory 3 which is used as working memory and with a non-volatile memory 4. The non-volatile memory 4 could be a solid state memory such as a flash memory chip. The CPU can also communicate with peripheral devices such as a display 5 and a keypad 6 and a cellular telecommunications transceiver 7. The phone also includes a BIOS memory 8 for use at the initial stage of boot-up.

When the phone is turned off the RAM 3 is powered down and its contents are lost. The user can turn the phone on by pressing a power key on the keypad 6. When the phone is turned on its hardware automatically causes a basic set of instructions stored in the BIOS memory to be executed by the CPU. Those instructions perform initial hardware checks and then cause a boot application to be loaded and run. Program code defining the boot application is stored in the non-volatile memory 4 as shown at 10. The basic instructions cause that code to be loaded into working RAM and then cause the CPU to start executing that code so as to run the boot application.

The object of the boot application is to put the phone in a state where it is ready for normal operation. In order to do that it needs to configure the working RAM with the necessary contents such as essential program code, device drivers and settings. It may also need to configure peripheral devices such as the display 5 (e.g. to display a splash screen and subsequently a default display environment) and the transceiver 7 (e.g. to cause it to establish connection to a network). For these purposes the boot application causes a series of other programs to be loaded and run. The program code defining those programs is stored in the non-volatile memory 4 as shown at 11.

One or more of the programs that are called by the boot application are dependent on one or more others of the programs in the sense that a dependent program cannot be successfully executed until such other programs have reached a certain point in their execution. That point may be the end of their execution or an intermediate point in their execution. The point that a program is required to reach before a dependent program can safely be allowed to run is referred to herein as a critical point. The boot application comprises a set of instructions defining the order in which the programs that it calls will be loaded into working RAM and the order in which they will be executed by the CPU. Where one program can be started once a preceding program has reached an intermediate point in its execution the instructions may also define that point. Whilst a dependent program cannot be executed until the or each program on which it depends has reached the required critical point, the dependent program can be loaded from non-volatile memory into working memory before the or each such program has reached the required critical point. The boot application of the phone of figure 1 is configured to load at least one program into working memory before the program(s) on which it depends have completed execution or otherwise reached the point at which the program being loaded can safely be run; and subsequently to cause the dependent program to execute when the program(s) on which it depends have finished execution.

This mechanism is illustrated in figure 2, which shows the activities over time of the BIOS and the boot application and of a set of programs A to E that are called by the boot application. For simplicity, it is assumed that the critical points are at the end of the respective programs' execution.

Program B depends on program A and program D depends on programs B and C. At turn-on the BIOS is automatically executed, performs certain key operations, loads the boot application into working memory and then passes control to the boot application. The boot application is programmed to run programs A, B, C, D and E in that order. It loads program A into working memory and then causes it to run. The boot application additionally causes program B to be loaded into working memory whilst program A is running, with the effect that program B has been fully loaded into memory by the time program A has completed. The boot application can therefore run program B immediately program A completes. Since the CPU is handling the running of program A and the loading of program B in parallel, if program A is blocked waiting for a response (e.g. from an item of hardware) the loading of program B can continue. This saves time over the conventional process since the time when process A is blocked is not wasted.

Similarly, loading of programs C and D into working RAM can be initiated whilst program B is running, so that program C can be run immediately program B completes. In this example program D also starts to be loaded into working RAM whilst program B is running, but does not complete loading until after program C has finished executing. Program D cannot therefore be run immediately program C finishes execution.

Program E is not loaded until after the preceding program has completed running. That might need to happen if, for example, there is insufficient working memory to hold program E until program D has completed a clean-up of the memory.

The phone's CPU may be capable of multi-threaded operation. In that case it may not be necessary for one process to complete before the next one is run by the boot application. The boot application could detect that a first process has fulfilled the preconditions for a dependent process to run, and the boot application could then start the dependent process running whilst the first process also continues running. This would result in the boot application causing multiple sup-processes to run in parallel to configure the memory for operation. In a multi-threaded environment it may also be convenient for the boot application to be made up of multiple processes. For example, one process of the boot application could handle the loading of the sub-programs and another process of the boot application could trigger those programs to run at the appropriate time.

The boot application could have access to a data set that defines the load and execution order of the processes and, if appropriate, the preconditions that must be met before each dependent process can be launched. The boot application can then interpret that data set to control the start-up process.

This has the advantage that the boot application itself can be independent of the particular start-up process that is to be adopted.

The present method can be implemented in a particularly convenient way when the boot application is being supported by an operating system that provides separate commands for loading and execution of applications. If the boot application is being supported by an operating system that automatically schedules loading and execution then the boot application could independently cause the processes to be loaded into working memory and then signal the operating system to execute them from there.

In current start-up schemes, in which programs are not loaded into working memory until they are ready to be run, the time taken for processes to load can have a significant impact on start-up time. In the method described above, when the boot sequence has dependencies which require processes to be executed in a certain order, the delay between the processes being ready for the boot to continue and the next process running can be reduced.

Thus by separating the loading of processes from the execution of processes the process load is removed from the more restrictive rules of execution, and therefore the start-up time can be quicker. The reduced start-up time may result from several factors. First, if a process that is being run is blocked then the loading process that is running in parallel with it can continue, meaning that processor time is not wasted. Second, the loading could be performed by a separate memory controller or another processing unit operating under the control of the boot application, which can carry out the loading process independently of the operation of the CPU.

The examples described above relate to the starting up of a device. Similar principles can be used when the memory of a device needs to be configured at other times, for example when a complex application that has a number of sub-processes is being loaded for use or when a new item of hardware is attached to the device. A loader process could load the sub-processes into memory and start them running in an analogous way to that described above: i.e. with one or more of the sub-processes being loaded into working memory whilst one or more other processes are running.

The device may be provided with specialised hardware for implementing the memory configuration system described herein (e.g. by being provided with hardware that is hard-wired to execute the operations to trigger the loading and execution of programs). The device may be configured by software to implement the memory configuration system (e.g. so that a processor of the device executes software code to execute the operations to trigger the loading and execution of programs). The device may also be provided with a combination of hardware and software for implementing the memory configuration system.

The memory configuration system may be implemented by means of a computer program, and suitably by an operating system of the device in which it is implemented. The program may be in the form of source code, object code, a code intermediate source and object code such as code in partially compiled form, or in any other form suitable for use in the implementation of processes according to the invention. The computer program may be on or in a carrier. The carrier may be any entity or device capable of carrying the program.

The present method is applicable to devices other than phones. It could be applied to any device having a memory that needs to be configured. Non-limiting examples include computers, media playback devices and automotive control units.

The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such feature or combination of features. In view of the foregoing description it will be evident to a person skilied in the art that various modifications may be made within the scope of the invention.

Claims

1. A data processing device having a working memory from which it can execute program code and a non-volatile memory for storing program code including code defining at least two programs that are executable to configure the device for operation, the device being arranged to perform a pre-defined sequence of operations in order to place itself in a ready state, the sequence comprising: loading the code for one of the programs into working memory of the processing device; executing that code from the working memory; and whilst that program is executing and before it has reached a state at which a second one of the programs can successfully be executed, loading the code for the second one of the programs into the working memory.

2. A data processing device as claimed in claim 1, wherein the non-volatile memory stores code defining a configuration control program, the configuration control program being executable by the device to cause it to perform the said pre-defined sequence of operations.

3. A data processing device as claimed in claim 2, wherein the device is arranged to execute the configuration control program automatically when the device is started up.

4. A data processing device as claimed in claim 2, wherein the device is arranged to execute the configuration control program automatically when an application is initiated on the device.

5. A data processing device as claimed in claim 2, wherein the device is arranged to execute the configuration control program automatically when an item of hardware is attached to the device.

6. A data processing device as claimed in any preceding claim, wherein the device comprises a data processor for executing the programs.

7. A data processing device as claimed in claim 6, wherein the data processor is capable of executing two or more processes in parallel, whereby the code for the second one of the programs can be loaded into working memory by a first thread whilst the first one of the programs is executing as a second thread.

8. A data processing device as claimed in any preceding claim, wherein the first one of the programs communicates during its execution with a peripheral hardware component of the device.

9. A data processing device as claimed in any preceding claim, wherein the device is arranged to load the code for the second one of the programs into the working memory at least during periods when execution of the first one of the programs is temporarily blocked.

10. A method for placing in a ready state a data processing device having a working memory from which it can execute program code and a non-volatile memory for storing program code including code defining at least two programs that are executable to configure the device for operation, the method comprising performing a pre-defined sequence of operations comprising: loading the code for one of the programs into working memory of the processing device; executing that code from the working memory; and whilst that program is executing and before it has reached a state at which a second one of the programs can successfully be executed, loading the code for the second one of the programs into the working memory.

11. A method as claimed in claim 10, wherein the non-volatile memory stores code defining a configuration control program, and the method comprises executing the configuration control program so as to cause the device to perform the said pre-defined sequence of operations.

12. A method as claimed in claim 11, comprising automatically executing the configuration control program automatically when the device is started up.

13. A method as claimed in claim 11, comprising executing the configuration control program automatically when an application is initiated on the device.

14. A method as claimed in claim 11, wherein comprising executing the configuration control program automatically when an item of hardware is attached to the device.

15. A method as claimed in any of claims 11 to 14, wherein the device comprises a data processor and the programs are executed by the data processor.

16. A method as claimed in claim 15, wherein the data processor is capable of executing two or more processes in parallel, whereby the code for the second one of the programs can be loaded into working memory by a first thread whilst the first one of the programs is executing as a second thread.

17. A method as claimed in any of claims 11 to 16, wherein the first one of the programs communicates during its execution with a peripheral hardware component of the device.

18. A method as claimed in any of claims 11 to 17, comprising loading the code for the second one of the programs into the working memory at least during periods when execution of the first one of the programs is temporarily blocked.

19. A computer program for placing in a ready state a data processing device having a working memory from which it can execute program code and a non-volatile memory for storing program code including code defining at least two programs that are executable to configure the device for operation, the said computer program comprising instructions for causing the device to perform a pre-defined sequence of operations comprising: loading the code for one of the programs into working memory of the processing device; executing that code from the working memory; and whilst that program is executing and before it has reached a state at which a second one of the programs can successfully be executed, loading the code for the second one of the programs into the working memory.

20. A data carrier storing a computer program as claimed in claim 19.