JP2008033877A - Information processing apparatus, OS activation method, and program - Google Patents

Abstract

In an embedded device having a multi-core CPU configuration, an arbitrary OS can be booted even after the initial boot OS is in a normal operation state.
When a startup of an OS to be started is requested after the initial startup OS is in a normal operating state, hardware management means notifies the current allocation status of hardware resources. The hardware allocation unit 301 refers to the booted OS hardware information table 253 indicating the hardware resources necessary for starting the OS, determines the hardware resources necessary for booting the booted OS 400, and Hardware resources are allocated to the booted OS based on the hardware resource allocation status notified from the hardware management unit 203 and the hardware resources necessary for booting the booted OS. The OS booting unit 201 boots the booted OS 400 using the hardware resource allocated by the hardware allocation unit 301.
[Selection] Figure 1

Description

  The present invention relates to a technique for starting a plurality of operating systems (OS), for example, a technique for starting a plurality of OSs in an embedded device having a multi-core processor configuration.

  In recent years, embedded devices such as home appliances have demands for improving processing capability in order to increase the functionality of the system, such as adding additional functions to conventional models. In response to such demands, a multi-core system has been introduced in which a plurality of arithmetic processing units (cores) of a CPU (Central Processing Unit) are provided to improve processing capability while suppressing an increase in power consumption.

  In order to efficiently use a computer equipped with a multi-core, it is necessary to improve the parallelism of processing and distribute the processing to each core. As an implementation method, it is conceivable to use a single OS that supports multi-core. However, in this case, the real-time property of the embedded device greatly depends on the real-time response performance of the OS used. For this reason, embedded devices equipped with multi-cores operate in real time by operating various OSs such as a general-purpose OS with GUI (Graphical User Interface) and network protocol functions, and a real-time OS (RTOS) with hard real-time performance for each core. It is conceivable to improve the parallelism of processing while ensuring the performance.

  FIG. 15 shows the configuration of a built-in device 2 equipped with a conventional multi-core. Conventional multi-OS booting means (method described in Non-Patent Document 1) will be described with reference to FIG.

  The embedded device 2 includes a hardware resource 100 (hereinafter simply referred to as hardware) equipped with a multi-core CPU, firmware 200 for starting up the OS, an OS (initial startup OS) 300 that is started after hardware reset, It comprises an OS (started OS) 400 that is activated by the initial activation OS 300.

The hardware 100 includes a CPU 101 and a CPU 102, a memory 111, a secondary storage device 121, and an input / output device 131.
The CPU 101 has a function of transferring the processing to the OS activation unit 201 of the firmware 200 by hardware reset.
The CPU 101 and the CPU 102 have an inter-CPU interrupt function, and a function of transferring processing to the OS activation unit 201 of the firmware 200 by an inter-CPU interrupt.
The memory includes an area A and an area B where each OS is loaded.
The secondary storage device 121 has a function of holding the initial boot OS binary 122 and the booted OS binary 123.
The input / output device 131 refers to, for example, a display, a keyboard, a serial console, a mouse, a network interface device, an infrared interface device, a USB (Universal Serial Bus) port, and has a function of performing input / output with respect to each OS.

The firmware 200 includes an OS activation unit 201 and an OS activation information table 500.
The OS activation unit 201 has a function of reading information in the OS activation information table 500 that is statically held by the firmware and performing booting of the OS according to this information.
The OS boot information table 500 holds boot information of the initial boot OS 300 and boot information of the booted OS 400. The contents of the information include a CPU number (starting CPU number) for interrupting between CPUs, a managed CPU number (managed CPU number), a managed memory area (managed memory area), an input / output device (managed input / output device), two An OS binary address, capacity, and entry address of the next storage device 121 are provided.

The initial boot OS 300 includes hardware start / stop means 302 and booted OS start means 303.
The hardware start / stop means 302 has a start / stop function for each hardware installed in the embedded device.
The booted OS booting means 303 acquires the boot CPU number of the booted OS 400 from the OS boot information table 500 on the firmware 200 and performs an inter-CPU interrupt for this CPU.

Next, a description will be given from the hardware reset of the embedded device to the startup of the initial startup OS 300 and the booted OS 400 in the prior art.
The OS activation unit 201 operates on the CPU 101 by hardware reset. The OS activation unit 201 acquires the CPU number on which it is operating.
Next, the OS booting means 201 uses this CPU number to search for the boot CPU number in the OS boot information table 500, and boot information of the initial boot OS 300 (management CPU number, management memory area, management input / output device, Secondary storage address etc.) is acquired, and the initial startup OS 300 is started using this information.
The initial startup OS 300 operates the OS startup unit 303 to be started during the OS initialization process.
The booted OS boot unit 303 acquires the boot CPU number from the boot information of the booted OS 400 in the OS boot information table 500, and issues an inter-CPU interrupt to the CPU. As a result, the OS activation unit 201 operates on the CPU 102.
The OS boot unit 201 boots the booted OS 400 in the same manner as the boot of the initial boot OS 300.
The above is the multiple OS startup procedure at the time of hardware reset in the embedded device equipped with the conventional multi-core.

Further, there is a technique described in Patent Document 1 as a startup method in a multiprocessor system.
JP-A-8-272756 IPSJ 66th National Conference 2D-6 Realization of Hybrid OS Environment on Single-Chip Multiprocessor-Implementation of Inter-OS Interface-

The conventional multi-OS boot method described in Non-Patent Document 1 includes a static OS boot information table 500 held by firmware (boot loader) and an initial boot OS 300 booted by hardware reset when the OS is booted. A plurality of OSs are activated by utilizing the fact that the activated OS activation means 303 is held. In this method, a plurality of OSs can be activated at the time of initialization processing after hardware reset. However, after the initialization processing is completed, there is a problem that any OS cannot be activated by a user instruction or the like.
In other words, since the hardware resources that can be used by the booted OS are fixedly set in the static OS startup information table, the hardware resources indicated in the OS startup information table are changed after the initialization process is completed. If it is used elsewhere, the booted OS cannot be started.

  The main object of the present invention is to solve the above-described problems. It is possible to start an arbitrary OS even after the initial startup OS enters a normal operation state, and a plurality of OSs. The main purpose is to allow hardware resources to be exchanged between OSs even after the OS is started.

An information processing apparatus according to the present invention includes:
An information processing apparatus having a plurality of OSs (Operating Systems) and hardware resources allocated to the plurality of OSs,
Hardware management means for managing the allocation status of hardware resources and notifying the allocation status of hardware resources when activation of any OS is requested;
When activation of any OS is requested, the hardware resources necessary for activation are referred to the activation hardware resource information indicated for each OS, and are necessary for activation of the booted OS requested to be activated. Hardware resources are determined, hardware resource allocation status is notified from the hardware management means, and hardware resource allocation status notified from the hardware management means and hardware resources required for booting the booted OS Hardware allocation means for selecting a hardware resource to be allocated to the booted OS based on the above, and allocating the selected hardware resource to the booted OS;
OS booting means for booting the booted OS using the hardware resources allocated by the hardware allocation means.

  In the present invention, since the hardware resources necessary for OS startup are dynamically selected, it is possible to start an arbitrary OS even after the initial startup OS is in the normal startup state.

Embodiment 1 FIG.
FIG. 1 shows the configuration of an embedded device 1 (information processing apparatus) equipped with a multi-core according to Embodiment 1 of the present invention.
The embedded device 1 includes a hardware resource 100 (hereinafter also simply referred to as hardware) equipped with a multi-core CPU, firmware 200 for starting an OS, and an OS (initial startup OS) 300 that is started after a hardware reset. The system includes an OS (started OS) 400 activated by the initial activation OS 300 and an OS activation information table 500 generated by the firmware 200.

The hardware 100 includes a CPU 101 and a CPU 102, a memory 111, a secondary storage device 121, and an input / output device 131.
The CPU 101 has a function of transferring processing to the initial boot OS booting unit 202 of the firmware 200 by hardware reset.
The CPU 101 and the CPU 102 have an inter-CPU interrupt function, and a function of transferring processing to the OS activation unit 201 of the firmware 200 by an inter-CPU interrupt.
The memory 111 includes an area A in which the OS activation information table 500 is loaded, an area B in which each OS is loaded, and an area C.
The secondary storage device 121 has a function of holding the initial boot OS binary 122 and the booted OS binary 123.
The input / output device 131 indicates, for example, a display, a keyboard, a serial console, a mouse, a network interface device, an infrared interface device, a USB port, and the like, and has a function of performing input / output with respect to each OS.

  The firmware 200 includes an OS boot unit 201, an initial boot OS boot unit 202, a hardware management unit 203, an initial boot OS boot information table 251, a hardware management table 252 (hardware allocation status information), and hardware information for the booted OS. A table 253 (startup hardware resource information) and a memory area division table 254 are provided.

The OS boot unit 201 has a function of reading the information of the OS boot information table 500 expanded in the area A of the memory 111 and performing booting of the OS according to this information.
The initial boot OS boot unit 202 has a function of reading the information of the initial boot OS boot information table 251, writing the OS boot information table 500 in the area A of the memory 111, and transferring the processing to the OS boot unit 201.
The hardware management unit 203 has a function of receiving a read instruction from the hardware allocation unit 301 of the initial startup OS 300, reading table information of the hardware management table 252, and returning a response to the hardware allocation unit 301 of the initial startup OS 300.
In addition, the hardware management unit 203 has a function of writing table information in the hardware management table 252 in response to a write instruction from the hardware allocation unit 301 of the initial startup OS 300. Note that the management here indicates that the hardware is managed by the OS.

The initial boot OS 300 includes hardware allocation means 301 and hardware start / stop means 302.
The hardware start / stop means 302 has a start / stop function for each hardware mounted on the embedded device 1.
The hardware allocating unit 301 has a function of obtaining hardware information necessary for booting the booted OS 400 from the booted OS hardware information table 253 of the firmware 200 in response to a boot OS 400 boot instruction from the initial boot OS 300.
Further, the hardware allocation unit 301 inquires of the hardware management unit 203 of the firmware 200 about the hardware management status.
Further, the hardware allocation unit 301 has a function of reporting the hardware managed by the booted OS 400 to the hardware management unit 203 of the firmware 200.
Further, the hardware allocation unit 301 has a function of generating the OS activation information table 500 based on the secured hardware and the activated OS hardware information table 253 of the firmware 200 and overwriting the area A of the memory 111. Furthermore, a function is provided for performing an inter-CPU interrupt to the corresponding CPU from the boot CPU information for the booted OS 400 in the OS boot information table 500.
Furthermore, the hardware allocation unit 301 has a function of calculating the capacity of an unmanaged memory area from the memory area division table 254.

  The booted OS 400 includes hardware start / stop means 401. The hardware start / stop means 401 has a function for starting and stopping each hardware mounted on the embedded device 1.

Here, the operation of the embedded device 1 according to the present embodiment will be outlined. A detailed description of the operation will be described later.
The hardware management unit 203 manages a hardware management table 252 (hardware allocation status information) indicating the allocation status of hardware resources, and an initial startup OS 300 that is started first among a plurality of OSs is started and initialized. When the activation of one of the other OSs (started OS 400) is requested after the activation OS 300 enters the normal operation state, the current hardware resource allocation status is notified.
The hardware allocating unit 301 refers to the booted OS hardware information table 253 (boot hardware resource information) in which the hardware resources necessary for booting the OS are shown for each OS, and the requested hardware resources for booting are requested. Hardware resources necessary for starting the boot OS 400 are determined, the hardware resource allocation status is notified from the hardware management means 203, and the hardware resource allocation status notified from the hardware management means 203 and the OS to be started A hardware resource to be allocated to the booted OS is selected based on the hardware resources necessary for booting, and the selected hardware resource is allocated to the booted OS 400.
Then, the OS activation unit 201 activates the activated OS 400 using the hardware resource allocated by the hardware allocation unit 301.
Also, the hardware management unit 203 reflects the allocation of the hardware resources to the booted OS 400 after the hardware allocation of the booted OS 400 by the hardware allocation unit 301, and reflects the hardware management table (hardware allocation status information). Update.

FIG. 2 shows an example of the contents of the initial boot OS boot information table 251 with which the firmware 200 is provided.
The initial startup OS startup information table 251 holds information for starting up the initial startup OS 300.
The contents of the information include the CPU number (starting CPU number) of the CPU that is operating when the initial startup OS 300 is operating, the CPU number (management CPU number) managed by the initial startup OS 300, the memory area (management memory area), and the input / output The secondary storage address, capacity, and entry address of the device and initial boot OS binary 122 are provided.
A plurality of management CPU numbers, management memory areas, and management input / output devices may exist.

FIG. 3 shows an example of the contents of the hardware management table 252 provided in the firmware 200.
The hardware management table 252 holds the management status of hardware.
Information contents include a CPU management status, a memory management status, and an input / output device management status.
“Under management” in FIG. 3 indicates that certain hardware is managed by the OS.
“Unmanaged” in FIG. 3 indicates that no OS is managed.
Further, even hardware managed by the OS may not be used (there may be unused hardware that is being managed but not used).

FIG. 4 shows an example of the contents of the booted OS hardware information table 253.
The booted OS hardware information table 253 holds hardware information necessary for booting each booted OS.
The contents of the information include the number of CPUs essential for starting the OS of the OS to be started, the required memory capacity, the required input / output device, the address of the OS to be started of the secondary storage device 121, the capacity, and the entry address. . Note that there may be a plurality of essential CPUs and input / output devices (the number of essential CPUs is two, or the essential input / output devices are a display, a keyboard, and the like).

FIG. 5 shows an example of the contents of the memory area division table 254.
The memory area division table 254 holds the start address and end address of each memory area (area A, area B, area C).
Thereby, the address and capacity of each memory area can be acquired. This address is set statically in the firmware.

FIG. 6 shows an example of the contents of the OS startup information table 500 expanded in the area A of the memory 111.
The OS activation information table 500 holds OS activation information used by the OS activation unit 201.
The contents of the information include a CPU number (starting CPU number) for interrupting between CPUs, a managed CPU number (managed CPU number), a managed memory area (managed memory area), an input / output device (managed input / output device), two An OS binary address, capacity, and entry address of the next storage device 121 are provided.

Next, the process from the hardware reset of the embedded device 1 to the end of the startup of the initial startup OS 300 and the normal operation state in this embodiment will be described with reference to FIG. Note that the processing shown in FIG. 7 is a conventional content.
First, by an external hardware reset, the CPU 101 moves the process to the initial startup OS startup unit 202, and the initial startup OS startup unit 202 executes the memory area (area A) described in the first entry of the memory area division table 254. ) Is reserved for the memory area division table 254, and the contents are expanded (S1002). The contents are set statically at the time of hardware reset.
Further, the initial startup OS startup unit 202 reserves a part of the area A of the memory 111 for the hardware management table 252 and updates the memory area A in the item of the memory management status of the hardware management table 252 during management. (S1003).
Next, the initial startup OS startup unit 202 reserves a part of the area A of the memory 111 for the OS startup information table 500, and copies the contents of the initial startup OS startup information table 251 to the OS startup information table 500 (S1004). ).
Further, the initial startup OS startup unit 202 reports the hardware (CPU = CPU 101, memory = area B, input / output device = display) managed by the initial startup OS 300 to the hardware management unit 203 from the OS startup information table 500. .
The hardware management unit 203 updates the hardware management table 252 in response to the report from the initial startup OS startup unit 202. As a result, the CPU 101 in the CPU management status item of the hardware management table 252 is managing, the memory area B in the memory management status item is being managed, and the display in the I / O management status item is being managed. (S1005).
Thereafter, the initial startup OS startup unit 202 moves the processing to the OS startup unit 201, and from the OS startup information table 500, from the secondary storage address information (0x7A1200) and capacity (0xF4240) of the OS startup information table 500, The position on the secondary storage device 121 is identified, the contents of the memory area division table 254 are acquired, and the initial boot OS binary 122 is loaded into the area B of the memory 111. Further, the OS activation unit 201 jumps to the address 0x7010 on the memory 111 using the entry address information (0x7010) in the OS activation information table 500 (S1006).
Thereby, the initialization process of the initial startup OS 300 is executed.
The initial startup OS 300 initializes each management hardware defined in the OS startup information table 500 during the OS initialization process. That is, the CPU 101 that is the management CPU, the area B that is the management memory area, and the display that is the management input / output device are initialized using the hardware start / stop unit 302 (S1007).
As described above, the startup of the initial startup OS 300 is completed, and the embedded device 1 enters a normal operation.

Next, an operation for starting the OS to be started 400 from the normal operation state of the embedded device 1 in this embodiment will be described with reference to FIG.
While the embedded device 1 is in a normal operation state, the user transmits a startup request for the OS to be started 400 to the hardware allocation unit 301 through the initial startup OS 300 (S1012).
The hardware allocation unit 301 acquires hardware information necessary for booting the booted OS 400 from the booted OS hardware information table 253 (S1013) (hardware allocation step).
The hardware allocation unit 301 inquires of the hardware management unit 203 about the current hardware management status (hardware resource allocation status) (S1014) (hardware allocation step).
The hardware management means 203 reads the management status (hardware resource allocation status) of each hardware from the hardware management table 252 and returns it to the hardware allocation means 301 (S1015) (hardware management step).
The hardware allocation unit 301 determines the hardware necessary for starting the booted OS 400 from the response result of the hardware management unit 203 and the information in the booted OS hardware information table 253. In the case of this embodiment, the number of CPUs required for starting the booted OS 400 is one from the booted OS hardware information table 253, and the unmanaged CPU is the CPU 102 from the response result of the hardware management unit 203. Therefore, the CPU 102 is selected and assigned to the booted OS 400. For the management memory area, the hardware allocation unit 301 acquires the contents of the memory area division table 254 for the unmanaged memory area C, and calculates the capacity of the memory area C (0x1E00000). Then, it is determined that the memory area C has a required memory capacity of 0x800000 or more in the booted OS hardware information table 253, and the memory area C is selected and allocated to the booted OS 400. As for the input / output device, since the serial console which is an indispensable input / output device is not managed, it is selected and assigned to the booted OS 400 (S1016) (hardware assignment step).

The hardware allocation unit 301 reports the hardware (CPU = CPU 102, memory = area C, input / output device = serial console) allocated to the OS 400 to be started to the hardware management unit 203 (S1017).
In response to the report from the hardware allocation unit 301, the hardware management unit 203 updates the hardware management table 252 by reflecting the hardware allocation result for the OS 400 to be started by the hardware allocation unit 301 (S1018).
Thereby, the CPU 102, the memory area C, and the serial console assigned to the OS 400 to be started are updated during management.

The hardware allocation unit 301 generates the OS startup information table 500 based on the hardware reserved for starting the booted OS 400 and the booted OS hardware information table 253, and the area of the memory 111 of the hardware 100. A is overwritten (S1019).
As a result, the OS startup information table 500 has the startup CPU as CPU 102, the management CPU as CPU 102, the management memory area as area C, the management input / output device as the serial console, the secondary storage address as 0x2625A000, the capacity as 0x1E8480, and the entry address as 0x7C00. Overwritten. In this state, the hardware allocation unit 301 issues an inter-CPU interrupt to the CPU (CPU 102) described in the activation CPU number of the OS activation information table 500 (S1020).
As a result, the CPU 102 is activated and the OS activation means 201 operates. Further, the hardware allocation unit 301 on the CPU 101 ends the processing and returns to the normal operation.
The OS boot unit 201 identifies the location on the secondary storage of the booted OS binary 123 from the OS binary secondary storage address information (0x2625A000) and the capacity (0x1E8480) in the OS boot information table 500, and the booted OS The binary 123 is loaded into the area C of the memory 111. Further, the OS activation unit 201 jumps from the entry address information (0x7C00) of the OS activation information table 500 to the address 0x7C00 on the memory 111. As a result, initialization processing of the OS to be started 400 is executed (S1021) (OS startup step).
The OS 400 to be started initializes each management hardware defined in the OS startup information table 500 during the OS initialization process. That is, the CPU 102 that is the management CPU, the area C that is the management memory area, and the serial console that is the management input / output device are initialized using the hardware activation / deactivation unit 401.
Thus, the booting of the booted OS 400 ends.

In the multi-OS boot method of the embedded device 1 equipped with a multi-core according to this embodiment,
An area for holding hardware information required by the booted OS and an area for managing hardware in the device are provided. The hardware managed by the booted OS is allocated based on this information, and is necessary for OS startup. Since the information is dynamically generated, it is possible to start an arbitrary OS even after the initial startup OS is in a normal startup state.

Although the memory area is divided into three in this embodiment, the same effect can be obtained even when the memory area is divided into four or more.
In addition, although there are two CPUs, the same effect can be obtained even if there are three or more CPUs.

Further, although one OS can be selected as the OS to be started, the same effect can be obtained even when there are a plurality of selectable OSs.
Although the activation request for the OS 400 to be activated is requested by the user, the same effect can be obtained by another application on the embedded device or a hardware interrupt.

Further, in the above example, the initial startup OS that is first started among the plurality of OSs includes hardware allocation means, and the initial startup OS is configured to respond to a booted OS that is requested to start after its own startup. The hardware allocation means allocates hardware resources. However, each OS includes hardware allocation means, and each OS provides hardware to a booted OS that is requested to start after its own startup. Hardware resources may be allocated by a hardware allocation unit.
In this way, there is an effect that the booted OS 400 can boot another OS from the booted OS 400 by holding the hardware allocation unit 301.
Furthermore, by holding the field for the initial boot OS in the OS hardware information table, the initial boot OS can also be booted from the booted OS.

The same effect can be obtained even if the address information of the memory area division table is dynamically set.
Further, the same effect can be obtained even if the initial boot OS startup information table and the booted OS hardware table statically existing in the firmware are expanded on the memory and dynamically changed.

As described above, in the present embodiment, in an embedded device having a plurality of CPU cores and having hardware such as a memory and an input / output device,
A hardware management table storing a flag that holds whether each hardware of the embedded device is being managed by the OS;
Hardware management means for updating hardware management information assigned to the booted OS according to a user instruction;
A hardware information table for a booted OS that stores hardware information for booting the booted OS;
Hardware allocation means for instructing the hardware management means to start the booted OS;
OS boot information table storing OS boot information updated each time the booted OS is booted;
An embedded apparatus having a memory area division table that divides a memory area and holds position information thereof has been described.

  Further, in the present embodiment, the hardware allocation unit allocates hardware managed by the booted OS based on the information of the booted OS hardware information table, the hardware management table, and the memory area division table, A description has been given of an embedded device that can start an arbitrary OS even after the initial startup OS is in a normal startup state by dynamically generating an OS startup information table.

Embodiment 2. FIG.
FIG. 9 shows the configuration of an embedded device 1 equipped with a multi-core according to Embodiment 2 of the present invention.
In the present embodiment, the secondary storage device 121 on the hardware 100 includes a booted OS boot user setting file 124.
The initial startup OS 300 also includes user setting hardware information creation means 304.
The firmware also includes a user setting hardware information table 255.

The user setting hardware information creation unit 304 has a function of generating the user setting hardware information table 255 from the information of the booted OS boot user setting file 124 and the booted OS hardware information table 253. In the present embodiment, the user setting hardware information creation unit 304 corresponds to a hardware resource determination unit.
The booted OS boot user setting file 124, which will be described in detail later, is information indicating the hardware requested by the user (requested hardware resource) for each OS, and the requested hardware resource. It corresponds to information.
In the present embodiment, the user setting hardware information creation unit 304 (hardware resource determination unit) performs the booted OS boot user setting file 124 as the requested hardware resource information and the booted OS as the boot hardware resource information. Is compared with the hardware information table 253, and it is determined whether or not the booted OS 400 can be booted with the requested hardware resource of the booted OS 400. Then, the user-set hardware information creation unit 304, when the booted OS 400 can be booted with the requested hardware resource of the booted OS 400, has a user-set hardware information table 255 indicating the requested hardware resource of the booted OS 400. Is generated.
When the user setting hardware information creation unit 304 determines that the booted OS 400 can be booted with the requested hardware resource of the booted OS 400, the hardware allocation unit 301 starts from the hardware management unit 203. A hardware resource to be allocated to the booted OS 400 is selected based on the notified hardware resource allocation status and the requested hardware resource of the booted OS 400 shown in the user-set hardware information table 255.

As described above, the user setting hardware information table 255 is generated by the user setting hardware information creation unit 304 from the contents of the booted OS hardware information table 253 and the booted OS boot user setting file 124.
The information to be held has the same contents as the booted OS boot user setting file 124.
The contents information of the booted OS hardware information table 253 is the same as that shown in FIG.
In other words, in the present embodiment, the hardware configuration at the time of booting the booted OS 400 is a configuration (more abundant hardware resources) than the minimum hardware configuration shown in the booted OS hardware information table 253. Is requested by the user in the booted OS boot user setting file 124, the booted OS 400 is booted using abundant hardware resources indicated in the booted OS boot user setting file 124. It is what.
The other configuration in FIG. 9 is the same as or equivalent to the configuration in FIG.

Next, a description example of the booted OS boot user setting file 124 is shown in FIG.
This file holds information (requested hardware resource information) assigned to the booted OS 400 among the hardware information necessary for booting the booted OS.
The contents of the information are the number of CPUs assigned to the OS 400 to be started (cpu = 1), the memory capacity to be assigned (mem = 0x800000), and the input / output device to be assigned (iodev = serial).
Note that there may be a plurality of CPUs and input / output devices (two CPUs or input / output devices such as a display and a keyboard). It is assumed that this file is prepared in advance by the user or application.

Next, an operation of starting the OS to be started 400 from the normal operation state of the embedded device 1 in this embodiment will be described with reference to FIG.
In this embodiment, the process is the same as that in FIG. 7 from the hardware reset of the embedded device 1 until the startup of the initial startup OS 300 is completed and the normal operation state is reached.
When the embedded device 1 is in a normal operation state, the user transmits a startup request for the OS 400 to be started to the user setting hardware information creation unit 304 through the initial startup OS 300 (S1032).
At this time, it is specified to use the booted OS boot user setting file 124 for booting the booted OS 400.
From the user setting file 124 for starting OS boot, the user setting hardware information creation unit 304 determines the number of CPUs to be allocated (cpu = 1), the memory capacity to be allocated (mem = 0x800000), the input / output device to be allocated (iodev = serial), The number of CPUs, the memory capacity, and the input / output device essential for starting the booted OS 400 are acquired from the boot OS hardware information table 253 and compared with these (S1033).
As a result of the comparison, if the hardware described in the booted OS boot user setting file 124 cannot be booted, an error is returned to the calling user (application) and the process is terminated (S1034).
If the hardware can be booted with the assigned hardware, the user setting hardware information table 255 is generated in the area A of the memory 111, and the number of CPUs to be assigned, the memory capacity, and the input / output device (CPU = 1), memory capacity = 0x800000, input / output device = serial), and the binary address, capacity, and entry address information of the OS 400 to be started on the secondary storage in the hardware information table 253 for the OS to be started Is written in the user setting hardware information table 255 secured in step S1035.
Thereafter, the activation of the booted OS 400 is transmitted to the hardware allocation unit 301 (S1036).
Since S1037 to S1039 are the same processes as S1013 to S1015 in FIG.
The hardware allocation unit 301 determines the hardware necessary for starting the booted OS 400 from the response result of the hardware management unit 203 and the information of the user setting hardware information table 255 (S1040).
In the case of this embodiment, the number of CPUs required to start up the booted OS 400 is one from the user setting hardware information table 255, and the CPU 102 is the unmanaged CPU from the response result of the hardware management unit 203. The CPU 102 is assigned to the booted OS 400.
For the management memory area, the hardware allocation unit 301 acquires the contents of the memory area division table 254 for the unmanaged memory area C, and calculates the capacity of the memory area C (0x1E00000). Then, it is determined that the memory area C has a required memory capacity 0x800000 or more in the user setting hardware information table 255, and the memory area C is allocated to the booted OS 400.
The input / output device is also assigned to the booted OS 400 because the serial console, which is an essential input / output device, is not managed.
S1041 to S1042 are the same processes as S1017 to S1018 of FIG.
The hardware allocation unit 301 generates the OS activation information table 500 based on the hardware reserved for activation of the activated OS 400 and the user setting hardware information table 255, and stores the OS activation information table 500 in the area A of the memory 111 of the hardware 100. Overwriting is performed (S1043).
Since S1044 to S1045 are the same processes as S1020 to S1021 in FIG.
Thus, the booting of the booted OS 400 ends.

  In the multi-OS boot method for an embedded device equipped with a multi-core according to this embodiment, an area for holding hardware information to be assigned to the booted OS according to a user instruction is provided, and the hardware information to be assigned to the booted OS based on this information Can be dynamically generated, so that it is possible to start an OS to which hardware designated / modified by the user is assigned.

  In this embodiment, the creator of the booted OS boot user setting file is a user, but the same effect can be obtained even if another application on the embedded device is created.

  As described above, in the present embodiment, a bootable OS boot user setting file that holds hardware information that can be generated by the user and is allocated to the bootable OS is provided, and this file and the bootable OS hardware information table Based on the above, it has a user setting hardware information creation means for generating a user setting hardware information table, and the hardware specified by the user is assigned from the hardware information set in the user setting hardware information table An embedded device that is characterized by starting a booted OS has been described.

Embodiment 3 FIG.
An embedded device 1 according to another embodiment of the present invention will be described.
The configuration of the embedded device 1 is the same as that of the first embodiment and is shown in FIG.
In the present embodiment, the configuration of the hardware management table 252 and the operations of the hardware management unit 203 and the hardware allocation unit 301 are the same as those in the first embodiment.

FIG. 12 shows an example of the contents of the hardware management table 252 provided in the firmware 200.
In the first embodiment, only the unmanaged flag is stored in the hardware management table 252 during the management of each device. However, in this embodiment, the management source OS and the unmanaged flag of each hardware are stored. And whether the OS uses hardware. The hardware management unit 203 has a function of changing these flags.
In other words, in the present embodiment, the hardware management unit 203 manages the allocation status of hardware resources and the usage status of hardware resources, and allocates hardware resources when activation of any OS is requested. The hardware allocation unit 301 is notified of the allocation status of the hardware resource and the usage status of the hardware resource by the hardware management unit 203, and is notified from the hardware management unit 203. The hardware resources to be allocated to the booted OS 400 are selected based on the allocation status of the hardware resources, the usage status of the hardware resources, and the hardware resources necessary for booting the booted OS 400.

Next, the process from the hardware reset of the embedded device 1 to the end of the startup of the initial startup OS 300 and the normal operation state in this embodiment will be described with reference to FIG.
However, in this embodiment, the CPU 101 and the CPU 102 are described as the management CPU numbers in the initial boot OS boot information table 251, and the rest are the same as those in FIG. 2.
Since S1052 is the same process as S1002 of FIG. 7, the description thereof is omitted.
The initial startup OS startup unit 202 reserves a part of the area A of the memory 111 for the hardware management table 252 and uses the memory usage status for the memory area A of the hardware management table 252 while the memory management status is in firmware management. (S1053).
Since S1054 is the same process as S1004 in FIG. 7, the description thereof is omitted.
The initial startup OS startup unit 202 reports the hardware (CPU = {CPU101, CPU102}, memory = area B, input / output device = display) managed by the initial startup OS 300 from the OS startup information table 500 to the hardware management unit 203. To do.
The hardware management unit 203 updates the hardware management table 252 in response to the report from the initial startup OS startup unit 202. As a result, the CPU management status of the CPU 101 in the hardware management table 252 is set to the initial startup OS 300 management. As for the CPU usage status, since the CPU 101 is operating upon receiving a CPU interrupt, since the CPU usage status of the CPU 101 is in use, the CPU 102 is described in the management CPU in the OS startup information table, and therefore the CPU management The status is set to be during initial startup OS 300 management. However, since the CPU 102 is not used, the CPU usage status of the CPU 102 is unused. As for other hardware management information, the memory management status of the memory area B is being managed by the initial startup OS 300, the memory usage status is being used, the input / output management status of the display is being initially managed by the OS 300, and the input / output usage status is being used. (S1055).
Steps S1056 to S1057 are the same as steps S1006 to S1007 in FIG.
As described above, the startup of the initial startup OS 300 is completed, and the embedded device 1 enters a normal operation.

Next, an operation of starting the OS to be started 400 from the normal operation state of the embedded device 1 in this embodiment will be described with reference to FIG.
Since S1062 to S1064 are the same processes as S1012 to S1014 in FIG.
The hardware management unit 203 reads the management status (allocation status) and usage status of each hardware from the hardware management table 252 and returns a response to the hardware allocation unit 301 (S1065).
Based on the response result of the hardware management unit 203 and the information of the booted OS hardware information table 253, the hardware allocation unit 301 determines whether the unmanaged hardware and the hardware that is being managed by the initial boot OS 300 and unused are used. If it is assigned to the boot OS 400, it is determined whether the boot OS 400 is booted (S1066).
In the case of the hardware management table 252 in FIG. 12, the CPU 101 and the CPU 102 are both managed by the initial startup OS 300, but the CPU 102 is unused, so the CPU 102 that is managing the initial startup OS 300 can be assigned to the OS 400 to be started. .
The management memory area and the input / output device are the same as those in the first embodiment. If the booted OS 400 does not start, an error is returned and the process ends (S1067).
If the CPU usage statuses of all CPUs are in use, there is no free CPU, and the booted OS 400 cannot be booted. In this case, an error is returned and the process is terminated. When the booted OS 400 is booted, the hardware boot / stop means 302 is used to stop only the hardware necessary for booting the booted OS 400 among the hardware that is being managed by the initial boot OS 300 and is not used ( S1068).
In this example, the initial startup OS 300 stops the CPU 102 being managed.
Since S1069 is the same process as S1017 in FIG.
The hardware management unit 203 updates the hardware management table 252 according to the report from the hardware allocation unit 301 (S1070).
As a result, the CPU 102, the memory area C, and the serial console assigned to the booted OS 400 are updated during management and use by the booted OS 400.
Steps S1071 to S1073 are the same as steps S1019 to S1021 in FIG.
Thus, the booting of the booted OS 400 ends.

  In this embodiment, the multi-OS boot method for embedded devices equipped with a multi-core has an area for storing information on the management source OS and usage status for each hardware, and based on this information, the initial boot OS Since unused hardware is added to the booted OS, the booted OS can be booted even when there is not enough hardware for booting the booted OS.

Embodiment 4 FIG.
In this embodiment, an embedded device having a configuration combining Embodiments 2 and 3 is shown, and when there are not enough hardware resources for the booted OS, it communicates with another OS and is used by another OS. A method for securing unassigned hardware and allocating it to the booted OS will be described.

FIG. 16 shows a configuration example of an embedded device 1 (information processing apparatus) equipped with a multi-core according to Embodiment 4 of the present invention.
The embedded device 1 has CPUs 101, 102, 103 and memory areas A, B, C, D. These functions are the same as those in the first embodiment, and a description thereof will be omitted.
Further, the embedded device 1 includes a booted OS 400 that is booted by the initial boot OS 300 and a booted OS 600 that is booted by the initial boot OS 300.
The booted OS 400 includes hardware allocation means 402.

The secondary storage device 121 has a function of holding the booted OS 600 binary 125 and the booted OS 600 boot user setting file 126.
Note that the booted OS 400 binary 123 and the booted OS boot user setting file 124 have been renamed to distinguish them from the booted OS 600. These are the booted OS binary 123 and the booted OS shown in the second embodiment. This is the same as or equivalent to the OS startup user setting file 124, and a description thereof is omitted.

In the present embodiment, except for the hardware management means 203 and the hardware allocation means 301 and 402, the booted OS 400 startup user setting file 124 on the secondary storage, the user setting hardware information table 255 on the firmware 200, the initial The user-set hardware information creation unit 304 on the boot OS 300 is the same as or equivalent to that in the second embodiment, and a description thereof is omitted.
Other configurations are the same as or equivalent to those of the third embodiment, and description thereof is omitted.

The hardware allocation unit 301 on the initial boot OS 300 and the hardware allocation unit 402 on the booted OS 400 are added to the functions described in the above embodiments, and the response of the hardware management unit 203 on the firmware. As a result, when hardware resources (CPU, memory, input / output device, etc.) are insufficient when starting up the booted OS 600, the hardware management unit 203 is again inquired about the hardware usage status of the other OS. Has function.
Further, when there is an inquiry about the hardware usage status of the own OS from the hardware management means 203 on the firmware, the hardware usage status of the own OS is investigated, and the hardware usage status is reported to the hardware management means 203. It has a function to do.

  In addition to the functions described in the above embodiments, the hardware management unit 203 on the firmware 200 adds to the hardware management table 252 when there is an inquiry about the status of another OS from the hardware allocation unit 301. Hardware allocation means on each OS other than the inquiry source for the OS that holds the hardware resources (CPU, memory, input / output device, etc.) necessary for starting the OS described Has a function to query

FIG. 17 shows an example of the contents of the memory area division table 254.
Except that the capacity and the number of divisions of the entire memory are different, they are the same as those in the third embodiment and will not be described.

FIG. 18 shows an example of the contents of the booted OS 400 startup user setting file 124 on the secondary storage device.
Except that the hardware to be allocated is different, it is the same as that of the second embodiment, and the description is omitted.

FIG. 19 shows an example of the contents of the booted OS 600 user setting file 126 on the secondary storage device.
The function of this file is the same as that of the booted OS 400 activation user setting file 124, and a description thereof will be omitted.

FIG. 20 shows an example of the contents of the booted OS hardware information table 253.
Except that an entry for the OS to be started 600 is added, this is the same as in the second embodiment, and a description thereof is omitted.

Next, an operation example from the hardware reset of the embedded device 1 to the startup of the initial startup OS 300 in this embodiment will be described with reference to FIG.
However, in this embodiment, it is assumed that only the CPU 101 is described as the management CPU number in the initial boot OS boot information table 251 (FIG. 2).

S1082 and S1083 are the same processing as S1052 and S1053 in FIG.
From the OS startup information table 500 (FIG. 6), the initial startup OS startup unit 202 stores the hardware (CPU = CPU 101, memory area = area B, input / output device = display) managed by the initial startup OS 300 in the hardware management unit 203. Report (S1084).
The hardware management unit 203 updates the hardware management table 252 (FIG. 3) in response to the report from the initial startup OS startup unit 202.
As a result, the CPU management status of the CPU 101 in the hardware management table 252 is set to the initial startup OS 300 management.
As for the CPU usage status, since the CPU 101 is operating upon receiving a CPU interrupt, the CPU usage status of the CPU 101 is set to being in use.
Other CPUs are set to unmanaged and unused because they are neither managed nor used in the initial boot OS.
As for other hardware management information, the memory management status of the memory area B is being managed by the initial startup OS 300, the memory usage status is being used, the input / output management status of the display is being initially managed by the OS 300, and the input / output usage status is being used. (S1085).
S1086 to S1087 are the same processes as S1056 to S1057 in FIG.

  As described above, the startup of the initial startup OS 300 ends, and the embedded device 1 enters a normal operation.

  Next, the procedure for starting the OS to be started 400 from the normal operation state of the embedded device 1 in this embodiment will be described with reference to FIG.

Since S1092 is the same process as S1032 of FIG. 11, the description thereof is omitted.
The user setting hardware information creation unit 304 determines the number of CPUs to be allocated (cpu = 2), the allocated memory capacity (mem = 0x1F00000), and the input / output device to be allocated (iodev = serial) from the user setting file 124 for starting the OS 400 to be started (FIG. 18). ) And the number of CPUs, memory capacity, and input / output devices necessary for starting the booted OS 400 are obtained from the booted OS hardware information table 253 (FIG. 20) and compared with these (S1093).
Since S1094 is the same process as S1034 in FIG. 11, the description thereof is omitted.
When the hardware can be started with the assigned hardware, the user setting hardware information table 255 is generated in the area A of the memory 111, and the number of CPUs to be assigned, the memory capacity, and the input / output device (CPU = CPU = 2), the memory capacity = 0x1F00000, iodev = serial), and the binary address, capacity, and entry address information of the booted OS 400 on the secondary storage in the booted OS hardware information table 253 are secured in the area A of the memory 111. Is written in the user setting hardware information table 255 (S1095).
Since S1096 to S1099 are the same processes as S1036 to S1039 in FIG.

Next, the hardware allocation unit 301 determines the hardware necessary for starting up the booted OS 400 from the response result of the hardware management unit 203 and the information in the user setting hardware information table 255 (S1100).
In the case of this embodiment, the number of CPUs necessary for starting up the booted OS 400 is two from the user setting hardware information table 255, and the unmanaged CPUs are determined by the CPU 102 and the CPU 103 from the response result of the hardware management unit 203. For this reason, the CPU 102 and the CPU 103 are allocated to the booted OS 400.
For the management memory area, the hardware allocation unit 301 acquires the contents of the memory area division table 254 for the unmanaged memory area C and memory area D, and calculates the capacities of the memory area C and memory area D. Then, by allocating the total capacity (0x3C00000) of the memory area C and the memory area D, it is determined that the capacity is equal to or larger than the memory capacity (0x1F00000) of the user setting hardware information table 255. Assigned to the OS 400 to be started.
The input / output device is also assigned to the booted OS 400 because the serial console, which is an essential input / output device, is not managed.
S1101 is the same process as S1041 in FIG.

Next, the hardware management unit 203 updates the hardware management table 252 in response to the report from the hardware allocation unit 301 (S1102).
As a result, the CPU 102 and CPU 103, the memory area C and the memory area D, and the serial console allocated to the booted OS 400 are updated during management and use.
Since S1103 to S1105 are the same processing as S1043 to S1045 of FIG.

Thus, the booting of the booted OS 400 ends.
The hardware management table 252 in the state so far is shown in FIG.

  Next, a procedure for starting the booted OS 600 from the state in which the initial boot OS 300 and the booted OS 400 are operating in the embedded device 1 in this embodiment will be described with reference to FIG.

While the initial boot OS 300 and the booted OS 400 are normally operating on the embedded device 1, the user transmits a boot request for the booted OS 600 to the user setting hardware information creation unit 304 through the initial boot OS 300 (S1112).
At this time, it is specified that the booted OS 600 boot user setting file 126 (FIG. 19) is used for booting the booted OS 600.
From the user setting file 126 for starting the OS to be started, the user setting hardware information creation unit 304 determines the number of CPUs to be assigned (cpu = 1), the memory capacity to be assigned (mem = 0x800000), the assigned input / output device (iodev = display), From the boot OS hardware information table 253 (FIG. 20), the required number of CPUs, memory capacity, and input / output devices necessary for booting the booted OS 600 are obtained and compared (S1113).
As a result of comparison, if the hardware described in the booted OS 600 boot user setting file 126 cannot be booted, an error is returned to the calling user (application) and the process is terminated (S1114).
If the hardware can be booted with the assigned hardware, the user-set hardware information creation unit 304 generates the user-set hardware information table 255 in the area A of the memory 111, and assigns the number of CPUs to be assigned to the booted OS 600 boot user setting file 126. , Memory capacity, input / output device (CPU = 1, memory capacity = 0x800000, input / output device = keyboard), booted OS hardware information table 253, binary address of the booted OS 600 on the secondary storage, capacity and The entry address information is written in the user setting hardware information table 255 secured in the area A of the memory 111 (S1115).
After that, the user setting hardware information creation unit 304 notifies the hardware allocation unit 301 of activation of the booted OS 600 (S1116).

The hardware allocation unit 301 acquires hardware information necessary for starting the booted OS 600 from the booted OS hardware information table 253 (S1117).
The hardware allocation unit 301 inquires of the hardware management unit 203 about the current hardware management status (S1118).
The hardware management unit 203 reads the management status of each hardware from the hardware management table 252 and returns it to the hardware allocation unit 301 (S1119).
The hardware allocation unit 301 determines whether hardware can be allocated to the booted OS 600 from the hardware management unit 203 and the booted OS hardware information table 253 (S1120).
In this case, the hardware resource (CPU = 1, memory = 0x800000) necessary for starting the booted OS 600 is received from the hardware management unit 203 as a response that another OS is already in use, and managed by itself. Since the hardware has no margin, it is determined that the booted OS 600 cannot be booted.
If the OS to be started cannot be started, the hardware allocation unit 301 inquires the hardware management unit 203 again about the current hardware usage status of the other OS. (S1127).

In response to the inquiry from the hardware allocation unit 301, the hardware management unit 203 uses the current hardware for all the OSs operating on the embedded device 1 except the request source OS. An inquiry is made to the hardware allocation means on the OS (S1128).
In this case, the hardware allocation unit 402 on the booted OS 400 is targeted.
The hardware allocation unit 402 on the OS 400 investigates the hardware usage status of the own OS and reports it to the hardware management unit 203 (S1129).
In this case, in response to an inquiry from the hardware management unit 203, the hardware allocation unit 402 investigates the hardware usage status of the booted OS 400 that is the own OS. The booted OS 400 is assigned the CPUs 102 and 103, the memory areas B and C, and the serial console. As a result of the investigation, if the CPU 103 and the memory area C are not used, the hardware assignment unit 402 It reports to the hardware management means 203 that the CPU 103 and the memory area C are unused.

The hardware management unit 203 updates the hardware management table 252 according to the report from the hardware allocation unit 402, and reports unused hardware information to the hardware allocation unit 301 (S1130).
In this case, the CPU 103 and the memory area C in the hardware management table 252 are changed to unused, and the fact that the CPU 103 and the memory area C are unused is reported to the hardware allocation unit 301.
Based on the report from the hardware management unit 203, the hardware allocation unit 301 determines again whether or not the booted OS 600 is started (S1131).
If it cannot be started, an error is returned to the calling user (application) and the process is terminated (S1132).
If it can be activated, the processing from S1121 to S1126 is performed.
Since these processes are the same as the processes from S1100 to S1105 in FIG. 22, the description thereof will be omitted.

  Thus, the booting of the booted OS 600 ends.

As described above, in the present embodiment, the hardware allocation unit 301 includes the already-launched OS (the above-described OS that is already activated when the activation of any one of the OSs to be activated (the activated OS 600 in the above description) is requested). In the description, when there is at least one booted OS 400), the hardware management unit 203 is inquired about the usage status of the hardware resources allocated to the started OS in the started OS, and a response from the hardware management unit 203 is received. Based on the above, the hardware resource to be allocated to the booted OS is selected.
In response to the inquiry from the hardware allocation unit 301, the hardware management unit 203 investigates the usage status of the allocated hardware resources in the activated OS, and sends a response indicating the survey result to the hardware allocation unit 301. Against.

The hardware allocation unit 301 compares the hardware resource allocation status notified from the hardware management unit 203 with the hardware resources necessary for booting the booted OS, and as a result, compares the hardware necessary for booting the booted OS. When it is determined that at least a part of the resources cannot be allocated, the hardware management unit is inquired about the usage status of the allocated hardware resources in the activated OS.
The hardware allocation unit 301 allocates hardware resources that are not used in the activated OS to the activated OS when the activated OS does not use hardware resources necessary for activation of the activated OS. Select as a hardware resource.

  In this embodiment, the multi-OS activation method for an embedded device equipped with a multi-core includes an area for storing information on the management source OS and usage status for each hardware, and each operating system based on this information. Since the OS is inquired about the hardware usage status and the hardware not used by each OS is assigned to the booted OS, the booted OS is booted using the latest hardware usage status information. It becomes possible.

In addition, the booted OS 600 is booted at the initial boot OS 300 this time, but the hardware allocation unit 402 on the booted OS 400 has the same function as the hardware allocation unit 301 on the initial boot OS 300. The booted OS 600 may be booted from the boot OS 400.
In addition, although the number of booted OSs is two at this time, there may be three or more booted OSs.
Also, this time, the hardware management means was used as a means for confirming the hardware usage status of the other OS. However, a means dedicated to confirming the other OS is prepared on the firmware, and this means confirms the hardware usage status of the other OS. The same effect can be obtained even if

  As described above, in the present embodiment, when the booted OS cannot be booted, the latest hardware of each OS on the embedded device is instructed by the hardware allocation means for inquiring the hardware usage status of the other OS and the hardware allocation means. An embedded device having hardware management means for acquiring the hardware usage status has been described.

  Further, in this embodiment, when the booted OS cannot be booted with the hardware resources of the own OS when booting the booted OS, there is hardware that can be used by inquiring about the hardware usage status of other OSs. In this case, the embedded device that enables the booting of an arbitrary OS by allocating the hardware to the booted OS has been described.

Embodiment 5. FIG.
In the present embodiment, a method of adding another hardware to an already started OS will be described.

FIG. 25 shows a configuration example of an embedded device 1 (information processing apparatus) equipped with a multi-core according to Embodiment 5 of the present invention.
In the present embodiment, the secondary storage device 121 on the hardware 100 includes an initial boot OS 300 hardware addition user setting file 127.

The hardware management unit 203 on the firmware 200 adds to the functions described in the above embodiments, and in response to a request for hardware addition from the hardware allocation unit 301 on the initial startup OS 300, the embedded device 1 The above hardware usage status is acquired from the hardware management table 252 and has a function of responding to the hardware allocation unit 301.
Further, in response to the inquiry of the hardware usage status of the other OS from the hardware allocation means 301, the hardware allocation status is inquired to the hardware allocation means on the OS other than the caller, and the hardware status is determined from the response result. It has a function of updating the management table and responding to the hardware allocation means of the caller.

  The hardware allocation unit 301 on the initial startup OS 300 adds to the functions described in the above embodiments, and responds to the hardware management unit 203 on the firmware 200 in response to a request for adding hardware resources from the user. It has a function of inquiring about the usage status of hardware.

  Similarly to FIG. 16, the hardware allocation unit 402 on each OS investigates the hardware usage status of its own OS in response to an inquiry from the hardware management unit 203 and returns a response to the hardware management unit 203.

Further, as will be described later, the user-set hardware information creation unit 304 sends a specific type of hardware resource to the hardware allocation unit 301 in a specific already-started OS (for example, the initial startup OS 300). Instructs additional allocations.
The user setting hardware information creation unit 304 is an example of a hardware addition instruction unit.

Next, a description example of the initial startup OS 300 hardware addition user setting file 127 is shown in FIG.
This file holds information on hardware to be newly allocated to the initial startup OS 300 after the initial startup OS 300 and the booted OS 400 are started and become normal.
The content of the information in this description example is the number of CPUs newly assigned to the initial boot OS 300 (CPU + = 1).
Although only the CPU is added this time, the hardware to be added may be a memory and an input / output device.
A plurality of hardware to be added may be described.
It is assumed that this file is prepared in advance by the user or application.

  The other configuration in FIG. 25 is the same as or equivalent to the configuration in FIG.

  Next, an operation of assigning hardware to the initial startup OS 300 according to a user instruction after the initial startup OS 300 and the OS to be started 400 are in a normal operation in this embodiment will be described with reference to FIG.

Note that the process from the hardware reset of the embedded device 1 to the end of the startup of the initial startup OS 300 in this embodiment is the same as that in FIG.
Further, since the startup of the initial startup OS 300 is completed and the startup OS 400 is started from the normal operation state, the description is omitted.

When the embedded device 1 is in a normal state, the user transmits the hardware addition on the initial startup OS 300 to the user setting hardware information creation unit 304 through the initial startup OS 300 (S1142).
At this time, the hardware information to be added to the initial startup OS 300 is specified to use the initial startup OS 300 hardware addition user setting file 127 (FIG. 26).

The user setting hardware information creation unit 304 acquires the number of CPUs to be added, the memory capacity, and the input / output device from the initial startup OS 300 hardware addition user setting file 127.
Further, the hardware information managed by the initial startup OS 300 is acquired from the hardware management unit 203 on the firmware 200, and these pieces of information are integrated and the user setting hardware secured in the area A of the memory 111. The data is written into the wear information table 255 (S1143).
Thereafter, the user setting hardware information creation unit 304 instructs the hardware allocation unit 301 to add hardware to the initial boot OS 300 (S1144).

The hardware allocation unit 301 receives an instruction to add hardware from the user-set hardware information creation unit 304 and inquires of the hardware management unit 203 on the firmware 200 about the management status of the hardware on the embedded device 1. This is performed (S1145).
The hardware management unit 203 checks the usage status of the hardware management table 252 and reports it to the hardware allocation unit 301 (S1146).
The hardware allocation unit 301 determines whether the hardware can be allocated to the initial boot OS 300 from the result of the report from the hardware management unit 203 and the user setting hardware information table 255 (S1147).
Processing when hardware can be assigned to the initial startup OS 300 is the same as S1148 to S1150 described later.

  In this case, since the hardware management unit 203 reports that there is no unused CPU, the hardware allocation unit 301 again queries the hardware management unit 203 about the current hardware usage status of the other OS. (S1151).

  In response to the inquiry from the hardware allocation unit 301, the hardware management unit 203 displays the current hardware usage status for all the OSs operating on the embedded device 1 except the request source OS. An inquiry is made to the hardware allocation means on each OS (S1152). In this case, the hardware allocation unit 402 on the booted OS 400 is targeted.

The hardware allocation unit 402 on the OS 400 investigates the hardware usage status of the own OS and reports it to the hardware management unit 203 (S1153).
In this case, in response to an inquiry from the hardware management unit 203, the hardware allocation unit 402 investigates the hardware usage status of the booted OS 400 that is the own OS.
The booted OS 400 is assigned the CPUs 102 and 103, the memory areas B and C, and the serial console. As a result of the investigation, if the CPU 103 and the memory area C are not used, the hardware assignment unit 402 It reports to the hardware management means 203 that the CPU 103 and the memory area C are unused.

The hardware management unit 203 updates the hardware management table 252.
In this case, the CPU 103 and the memory area C are changed to unused.
Thereafter, the hardware management unit 203 reports unused hardware to the hardware allocation unit 301 (S1154).

The hardware allocation unit 301 determines whether hardware can be allocated to the initial boot OS 300 from the report of the hardware management unit 203 and the user setting hardware information table 255 (S1155).
If hardware cannot be assigned to the initial startup OS 300, an error is returned to the calling user (application) and the process is terminated (S1156).
When hardware can be allocated to the initial startup OS 300, the hardware allocation unit 301 reports the hardware used by the initial startup OS 300 to the hardware management unit 203.
In this case, the use of the CPU 103 is reported to the hardware management means 203 (S1148).

The hardware management unit 203 updates the hardware management table 252 from the report of the hardware allocation unit 301 (S1149).
The hardware allocation unit 301 uses the hardware startup / stop unit 302 to make the additional hardware available to the initial startup OS 300.
In this case, the CPU 103 can be used by the initial startup OS 300 (S1150).

  As described above, after the initial boot OS 300 and the booted OS 400 are in normal operation, the user can newly assign hardware to the initial boot OS 300.

As described above, in the present embodiment, the user setting hardware information creation unit 304 (hardware addition instruction unit) sends a specific booted OS (described above) to the hardware allocation unit 301. Then, the initial booting OS 300) is instructed to additionally allocate a specific type of hardware resource, and the hardware allocation unit 301 assigns the specific type of hardware resource from the user setting hardware information creation unit 304 to the specific started OS. When there is an additional assignment instruction and there is a booted OS (booted OS 400 in the above description) other than the specific booted OS, the assignment is made to a booted OS other than the specific booted OS. Queries the hardware management means 203 about the usage status of the already-executed hardware resources in other activated OSs. , Based on the response from the hardware management unit 203 selects the hardware resources to the additional allocation to specific Started OS.
In response to the inquiry from the hardware allocation unit 301, the hardware management unit 203 investigates the usage status of the allocated hardware resources in another activated OS (the activated OS 400), and sends a response indicating the investigation result to the hardware. This is performed on the hardware allocation unit 301.

  Further, in the present embodiment, the hardware allocating unit 301 is configured to use a specific type of hardware that is not used in another started OS when a specific type of hardware resource is not used in another started OS. The resource is selected as a hardware resource to be additionally allocated to a specific activated OS.

  As described above, according to the present embodiment, the multi-OS boot method for embedded devices equipped with a multi-core includes an area for holding hardware information to be added to an operating OS, and based on this information, Since a function for inquiring hardware that can be assigned to each OS is added, it is possible to add hardware to the OS using the latest hardware usage information.

In this case, for the initial startup OS 300 hardware addition user setting file, the hardware resource is specified as a relative value, but may be specified as an absolute value (CPU = 2 or the like).
Further, although the OS to which hardware is added is the initial boot OS 300, the same effect can be obtained by using the booted OS 400.

  In the present embodiment, an embedded device having an OS hardware addition user setting file that holds additional hardware information for an OS that has already been activated has been described.

  In addition, when a user setting file for adding OS hardware that can be generated by the user is provided, the usage status of the hardware described in this file is inquired of another OS, and there is unused hardware In the above, an embedded device that adds hardware to an already running OS has been described.

Embodiment 6 FIG.
In the present embodiment, a method for deleting hardware from an already running OS will be described.

  FIG. 28 shows an example of the configuration of an embedded device 1 (information processing apparatus) equipped with a multi-core according to Embodiment 6 of the present invention.

  In the present embodiment, the hardware management unit 203 on the firmware 200 changes the corresponding hardware in the hardware management table 252 to unused based on the update request from the booted OS 400.

  In addition to the functions described in the above embodiments, the hardware allocation unit 402 on the booted OS 400 deletes the hardware by a request to delete the hardware used by the OS. A function of determining whether or not the OS is operable, and if so, deleting the corresponding hardware from the booted OS 400 and reporting to the hardware management means 203 that the hardware has been deleted. Have.

  In addition to the functions described in the above embodiments, the booted OS hardware information table 253 operates when the hardware resource is deleted from the booted OS 400 even after the hardware is deleted. It has a function that is used to determine whether it is possible.

Further, as will be described later, the user-set hardware information creation unit 404 determines whether or not the booted OS 400 can continue the operation even if the allocation of a specific type of hardware resource is canceled from the booted OS 400 that has already been booted. If it is determined and the continuous operation of the booted OS 400 is possible even if the allocation of the specific type of hardware resources is cancelled, the allocation of the specific type of hardware resources in the booted OS 400 is canceled to the hardware allocation unit 402 Instruct them to do so.
The user setting hardware information creation unit 404 is an example of a hardware release instruction unit.

Next, a description example of the booted OS 400 hardware deletion user setting file 128 is shown in FIG.
This file holds information on hardware to be deleted from the booted OS 400 after the initial boot OS 300 and the booted OS 400 are booted and become a normal state.
The content of the information is the number of CPUs to be deleted from the booted OS 400 (CPU- = 1). Although only the CPU is deleted this time, the hardware to be deleted may be a memory and an input / output device.
A plurality of hardware to be deleted may be described.
It is assumed that this file is prepared in advance by the user or application.

  The other configuration in FIG. 28 is the same as or equivalent to the configuration in FIG.

  Next, with reference to FIG. 30, the operation of deleting the hardware used by the booted OS 400 in accordance with a user instruction after the initial boot OS 300 and the booted OS 400 are in normal operation in this embodiment will be described. To do.

Note that the process from the hardware reset of the embedded device 1 to the end of the startup of the initial startup OS 300 in this embodiment is the same as that in FIG.
Further, since the startup of the initial startup OS 300 is completed and the startup OS 400 is started from the normal operation state, the description is omitted.

When the embedded device 1 is in a normal state, the user notifies the user setting hardware information creation unit 404 of deletion of hardware being used by the booted OS 400 through the initial boot OS 300 (S1162).
At this time, the hardware information to be deleted from the booted OS 400 is designated to use the booted OS 400 hardware deletion user setting file 128 (FIG. 29).

The user-set hardware information creation unit 404 stores the information on the booted OS hardware information table 253 and the booted OS 400 hardware deletion user setting file 128 after the specified OS is deleted. It is determined whether or not operation is possible (S1163).
If it cannot be operated, an error is returned to the calling user (application) and the process is terminated (S1164).

When operating, the user setting hardware information creation unit 404 instructs the hardware allocation unit 402 to delete the designated hardware (S1165).
In this case, an instruction is given to delete one CPU.

The hardware allocation unit 402 uses the hardware start / stop unit 401 to stop the use of the corresponding hardware from the booted OS 400 and updates the specified hardware information to the hardware management unit 203. Is instructed to do so (S1166).
In this case, for example, the use of the CPU 102 is stopped, and the hardware management unit 203 is instructed to update the usage status of the CPU 102.

The hardware management unit 203 changes the designated hardware to unmanaged and unused (1167).
As described above, it is possible to delete hardware from the booted OS 400 according to a user instruction.

As described above, in the present embodiment, the user-set hardware information creation unit 404 (hardware release instructing unit) performs a specific type of operation from a specific started OS (started OS 400 in the above description). It is determined whether or not the continuous operation of a specific activated OS can be performed even if the allocation of the hardware resources is released with reference to the activated hardware resource information of the specific activated OS, and the specific types of hardware resources are determined. If the continuous operation of a specific activated OS is possible even after the allocation is canceled, the hardware allocation unit 402 is instructed to cancel the allocation of a specific type of hardware resource in the specific activated OS.
The hardware allocation unit 402 then deallocates a specific type of hardware resource in a specific activated OS in accordance with an instruction from the user setting hardware information creation unit 404.

  In the multi-OS boot method of an embedded device equipped with a multi-core according to the present embodiment, an area for holding information on deleted hardware for another OS already started is provided, and when hardware is deleted from another OS Compares the information in this area with the minimum conditions for operating the OS and determines whether or not the OS can be deleted. Therefore, it is possible to delete hardware from another operating OS.

In this embodiment, the CPU is deleted, but it may be a memory or an input / output device.
Although the hardware assigned to the booted OS 400 is deleted from the initial boot OS 300 this time, the same effect can be obtained by deleting the hardware of the initial boot OS 300 from the booted OS 400.

  As described above, the present embodiment has described the embedded device having the OS hardware deletion user setting file that holds the information of the deletion hardware for the OS that has already been started.

  In this embodiment, an OS hardware deletion user setting file that can be generated by the user is provided, and for the booted OS that holds the hardware described in this file and information on the minimum operating requirements of the OS. The information of the hardware information tables is compared to determine whether the hardware specified by the user can be deleted. If the hardware can be deleted, the embedded device that deletes the hardware from the OS has been described.

Embodiment 7 FIG.
In the present embodiment, when hardware is available in a plurality of OSs, which OS hardware is allocated is based on the priority of the OS using the hardware or processes on the OS. Assign hardware.

  FIG. 31 shows a configuration example of an embedded device 1 (information processing apparatus) equipped with a multi-core according to Embodiment 7 of the present invention.

The priority determination means 204 on the firmware 200 is based on the priority setting tables 351, 451, and 651 on each OS when a plurality of hardware resources are unused in each OS on the embedded device 1. It has a function of acquiring the priority of a task (or process) and the hardware used by the task and storing it in the priority management table 256.
Furthermore, the priority determination unit 204 has a function of applying the information in the priority management table 256 to a certain algorithm, determining the hardware with the lowest priority, and reporting it to the hardware management unit.
As a method for determining the priority of hardware in the priority determination means 204, for example, an evaluation formula as shown in FIG. 32 is conceivable.
In this case, it is assumed that the priority for each OS and the priority of tasks in the OS are defined, and that a plurality of tasks share hardware.

The priority management table 256 on the firmware 200 has a function of integrating the contents of the priority setting tables 351, 451, and 651 of each OS, and holding information necessary for calculating the priority.
FIG. 33 shows an example of the contents of the priority management table 256. This file holds the priority of each OS, the priority of the task on each OS in the OS, and the hardware used by each task.
Furthermore, the OS priority minimum value, OS priority maximum value, task priority minimum value, and task priority maximum value for each OS are held as items necessary for calculating the priority.

  In addition to the functions described in the previous embodiments, the hardware management unit 203 determines which hardware priority is given to the priority determination unit 204 when a plurality of hardware on each OS is unused. It has a function of inquiring whether the degree is the lowest and allocating the hardware that has been answered from the priority determination means 204 to the booted OS.

The priority setting table 351 on the initial startup OS 300 has a function of holding the priority of tasks operating on the initial startup OS 300 and information on hardware used by the tasks.
Since the priority setting tables 451 and 651 on the other OS also have the same function, description thereof will be omitted.

  The other configuration in FIG. 31 is the same as or equivalent to the configuration in FIG. 28, and a description thereof will be omitted.

  Next, in this embodiment, a procedure for starting the booted OS 700 after the initial boot OS 300, the booted OS 400, and the booted OS 600 are booted and are in a normal state will be described with reference to FIG.

Note that the procedure for starting the initial startup OS 300 is omitted because it is the same as that in FIG.
Also, the procedure for starting the OS to be started 400 is the same as that in FIG.
Further, the procedure for starting up the OS to be started 600 is omitted because it is the same processing as in FIG.
However, since the hardware used by each OS is slightly different, FIG. 34 shows a hardware management table after the initial boot OS 300, the booted OS 400, and the booted OS 600 are started and become normal.
FIG. 35 shows an example of the contents of the booted OS 700 boot user setting file 130 assigned to the booted OS 700.

The user transmits a startup request for the OS to be started 700 to the user setting hardware information creation unit 304 through the initial startup OS 300 (S1172).
At this time, it is specified that the booted OS 700 boot user setting file 130 (FIG. 35) is used for booting the booted OS 700.
From the user setting file 130 for starting the OS 700 to be started, the user setting hardware information creation unit 304 determines the number of CPUs to be assigned (CPU = 1), the amount of memory to be assigned (mem = 0x800000), the assigned input / output device (iodev = network), From the OS hardware information table 253, the CPU count, memory capacity, and input / output device essential for starting the booted OS 700 are acquired and compared (S1173).
As a result of the comparison, if the hardware described in the booted OS 700 boot user setting file 130 cannot be booted, an error is returned to the calling user (application) and the process is terminated (S1174).

If the hardware can be booted with the assigned hardware, the user-set hardware information creation unit 304 generates the user-set hardware information table 255 and assigns the number of CPUs, memory capacity, and input / output of the booted OS 700 boot user setting file 130. The binary address, capacity, and entry address information of the boot OS 700 in the secondary storage of the device and the boot OS hardware information table 253 are written in the user setting hardware information table 255 (S1175).
Thereafter, the user setting hardware information creation unit 304 notifies the hardware allocation unit 301 of the activation of the booted OS 700 (S1176).

The hardware allocation unit 301 inquires of the hardware management unit 203 about the hardware management status (S1177).
The hardware management means 203 reads the management status of each hardware from the booted OS hardware information table 253, and returns it to the hardware allocation means 301 (S1178).
The hardware allocation unit 301 compares whether the hardware can be allocated to the booted OS 700 from the response result of the hardware management unit 203 and the information of the user setting hardware information table 255 (S1179).
If hardware can be assigned to the booted OS 700, the processing from S1190 to S1195 is performed.
Since this process is the same as S1121 to S1126 in FIG.

In this case, the memory capacity and input / output devices can be assigned to the booted OS 700, but since all the CPUs on the embedded device 1 are in use, one CPU can be assigned to the booted OS 700. Can not.
Therefore, the hardware allocation unit 301 makes an inquiry to the hardware management unit 203 again about the hardware usage status of the OS on the embedded device 1 (S1180).
The hardware management unit 203 acquires the usage status of the hardware on each OS (S1181, S1182), updates the hardware management table 252 and returns it to the hardware allocation unit 301 (S1183).
This time, for example, the CPU 102 on the booted OS 400 and the CPU 104 on the booted OS 600 are returned to the hardware allocation unit 301 to indicate that they are unused.

The hardware allocation unit 301 determines whether or not the booted OS is started by allocating unused hardware (S1184).
If it cannot be started, an error is returned to the calling user (application) and the process is terminated (S1185).
In this case, since the CPU 102 and the CPU 104 are not used, it is determined that the CPU 102 and the CPU 104 are started up if they are assigned to the booted OS 700.

  Next, the hardware allocation unit 301 determines whether or not more hardware than necessary is unused (the hardware to be allocated has a margin) from the hardware management unit 203 (S1186).

If unnecessary hardware is not unused, that is, if a minimum amount of hardware is allocated, the processing from S1190 to S1195 is performed.
Since this process is the same as S1121 to S1126 in FIG.

  If more hardware than necessary is unused, the hardware allocation unit 301 inquires of the priority determination unit 204 about the priority of the hardware (1187).

The priority determination unit 204 acquires the contents of the priority setting tables 351, 451, and 651 held by each OS, updates the priority management table 256, and determines the priority of the inquired hardware based on a certain determination. The degree is determined and returned to the hardware allocation means 301 (S1188).
In this case, when the priority is calculated using the calculation formula for calculating the priority shown in FIG. 32 and the information in the priority management table 256 shown in FIG. 33, the priority of the CPU 102 is 6.4, and the CPU 104 The CPU 102 calculates that the priority is lower and returns it to the hardware allocation unit 301.

The hardware allocation unit 301 allocates hardware with low priority to the booted OS 700 from the response result of the priority determination unit 204 (S1189).
In this case, it is necessary to assign either the CPU 102 or the CPU 104. However, since the CPU 102 has replied that the priority is lower, the CPU 102 is assigned to the booted OS 700.
In addition, the area E is allocated to the memory, and the network is allocated to the booted OS 700 regarding the input / output device.
Subsequent S1191 to S1195 are the same processing as S1122 to S1126 in FIG.
Thus, the booting of the booted OS 700 is completed.

  As described above, in the present embodiment, the hardware allocation unit 301 uses a plurality of hardware resources of the same type in at least one booted OS (the initial boot OS 300 and the booted OS 400 and 600 in the above description). In the case where it is determined that the plurality of hardware resources of the same kind are the hardware resources necessary for starting the booted OS (booted OS 700 in the above description), the priority for each of the plurality of hardware resources of the same kind Based on the above, any one of a plurality of hardware resources of the same kind is assigned to the booted OS.

  Further, in the present embodiment, the priority determination unit 204, according to the inquiry from the hardware allocation unit 301, the priority of the booted OS to which each of the plurality of similar hardware resources is allocated, and the plurality of similar types The priority of each of a plurality of hardware resources of the same type is determined using at least one of the priorities of the tasks to which each of the hardware resources is allocated. Based on the priority determination by 204, any one of a plurality of hardware resources of the same type is assigned to the booted OS.

  According to this embodiment, the multi-OS boot method for an embedded device equipped with a multi-core has an area for holding the priority of each OS and the priority of a task in each OS. Since the hardware to be allocated is determined, when the hardware is allocated to the booted OS, the hardware can be efficiently allocated.

In the present embodiment, the formula in FIG. 32 is used as a priority calculation example, but the same effect can be obtained by using another algorithm for determining priority.
Further, when determining the priority, the same effect can be obtained even if the priority is determined by the load determination module provided in the hardware, instead of using an algorithm.
Moreover, although only the CPU is targeted for allocation this time, the same effect can be obtained for the memory and other hardware.

  As described above, in the present embodiment, the priority of each OS, the priority management table that holds information on tasks on each OS, the information on the priority management table, and the hardware priority are calculated. The embedded device having the priority determination means for determining the priority of the hardware using the algorithm is described.

  In the present embodiment, the priority management table is provided, and the embedded device that can assign the hardware determined by the priority determination means to the booted OS using the information in this area has been described.

Embodiment 8 FIG.
In the present embodiment, a description will be given of a format in which the lowest priority resource is allocated to the booted OS when there is no available space in the hardware.

The configuration of the embedded device 1 is the same as that of the seventh embodiment and is as shown in FIG.
The present embodiment is the same as the seventh embodiment except for the operation of the hardware assignment unit 301.

  Next, in this embodiment, a procedure for starting the booted OS 700 after the initial boot OS 300, the booted OS 400, and the booted OS 600 are booted and are in a normal state will be described with reference to FIG.

Note that the procedure for starting the initial startup OS 300 is omitted because it is the same as that in FIG.
Also, the procedure for starting the OS to be started 400 is the same as that in FIG.
Further, the procedure for starting up the OS to be started 600 is omitted because it is the same processing as in FIG.
However, since the hardware used by each OS is slightly different, FIG. 34 shows a hardware management table after the initial boot OS 300, the booted OS 400, and the booted OS 600 are started and become normal.
FIG. 35 shows an example of the contents of the booted OS 700 boot user setting file 124 assigned to the booted OS 700.
FIG. 37 shows an example of the priority management table after OS startup.
The information held is the same as the priority management table shown in FIG.

Steps S1202 to S1214 are the same as steps S1172 to S1184 in FIG.
Next, when the booted OS 700 is not booted with the hardware allocated to the booted OS 700 as a result of the inquiry to another OS, the hardware allocation unit 301 sends the hardware with the lowest priority to the priority determination unit 204. Inquire.
In this case, one CPU is required to start the booted OS 700. However, if there is no unused CPU in the initial boot OS 300, the booted OS 400, and the booted OS 600, the hardware allocation unit 301 The CPU having the lowest priority among the CPUs used by each OS is inquired (S1215).

The priority determination means 204 acquires the hardware priority from the priority management table 256, and instructs the hardware start / stop means on each OS to stop the hardware with the lowest priority (S1226). However, when calculating the hardware priority, if the OS cannot be operated when the hardware having the lowest priority is deleted from the OS, based on the information in the hardware information table 253 for the booted OS, The hardware is removed from the hardware to be assigned to the booted OS 700.
In this case, the hardware priority of the CPU 101 is 0.4, the hardware priority of the CPU 102 is 6.4, the hardware priority of the CPU 103 is 20, the hardware priority of the CPU 104 is 11.2, and the CPU 105 The hardware priority is calculated as 48.
However, from the information in the booted OS hardware information table 253, since the initial boot OS 300 requires at least one CPU, the CPU 101 is excluded from the hardware to be assigned to the booted OS 700, and the priority determination unit 204 Instructs the hardware start / stop means 401 of the OS 400 to be started to stop the CPU 102 which is the next lowest priority hardware.

  The hardware start / stop unit on the OS stops the hardware instructed from the priority determination unit 204 and returns a response to the priority determination unit 204 (S1227).

  Next, the priority determination unit 204 returns the hardware with the lowest priority to the hardware allocation unit 301 (S1228).

The hardware assigning unit 301 assigns the hardware including the hardware with the lowest priority that has been replied to the booted OS 700 (S1229).
In this case, CPU = CPU 102, memory = area E, and input / output device = network are assigned as hardware.

  Since S1216 to S1225 are the same as S1186 to S1195 in FIG. 36, description thereof will be omitted.

  Thus, the booting of the booted OS 700 is completed.

  As described above, in the present embodiment, the hardware allocation unit 301 performs the specific type of hardware allocated to each activated OS when there is no free space of the specific type of hardware resources in any activated OS. Any specific type of hardware resource is allocated to the booted OS based on the priority for the hardware resource.

  Further, in the present embodiment, whether the priority determination unit 204 can continue the operation even if the allocation of a specific type of hardware resource is canceled for each activated OS in accordance with the inquiry from the hardware allocation unit 301. Is determined with reference to the activated hardware resource information of each activated OS, the priority of a specific type of hardware resource allocated to the activated OS capable of continuing operation is determined, and hardware allocation means 301 assigns any specific type of hardware resource to the booted OS based on the priority determination by the priority determination unit 204.

  Further, the priority determination unit 204 uses at least one of the priority of each activated OS and the priority of a task to which a specific type of hardware resource is allocated in each activated OS. Determine the priority for each of the wear resources.

  In this embodiment, the multi-OS startup method for embedded devices equipped with a multi-core has an area for holding the priority of each OS and the priority of a task in each OS. Since the hardware being used is assigned to the booted OS, the booted OS can be booted even when the hardware is occupied by the already booted OS.

In this embodiment, the initial boot OS 300 boots the OS, but the same effect can be obtained even when the booted OS 400 and the booted OS 600 boot the booted OS 700.
The priority determination means may determine an OS that cannot operate when the hardware is deleted, and then determine the priority of each hardware by excluding the hardware assigned to the OS. Or, conversely, after determining the priority for all hardware, determine the OS that cannot continue operation if the hardware is deleted, and exclude the hardware assigned to the OS. Also good.

  As described above, in the present embodiment, the priority of each OS, the priority management table that holds information on tasks on each OS, the information on the priority management table, and the hardware priority are calculated. The embedded device having the priority determination means for determining the priority of the hardware using the algorithm is described.

  Further, in this embodiment, when there is not enough hardware to be allocated to the booted OS, the boot has already been started from the information of the booted OS hardware information table that holds information on the minimum operating requirements of the OS. It is determined whether or not the hardware can be deleted from the OS. If more hardware than the minimum operation requirement is assigned to the OS that has already started, the OS is using the hardware. Even in such a case, the embedded device that starts the booted OS even when hardware for booting the booted OS is insufficient by forcibly assigning the hardware allocation to the booted OS has been described.

  As described above, in this embodiment, an area for storing the management source OS and the hardware usage status is provided in the hardware management table, and the hardware that is being managed by the initial boot OS and unused is allocated to the boot OS. Thus, the embedded device that starts the OS to be started has been described.

  Note that the embedded device 1 according to the first to eighth embodiments includes, for example, a communication board, a display device, a keyboard, a mouse, and the like in addition to the configuration of FIG. 1, FIG. 9, FIG. 16, FIG. 25, FIG. May be provided. Furthermore, it may be configured to be connectable to an FDD (Flexible Disk Drive), a compact disk device (CDD), a memory card, or the like.

  When the communication board is provided, the embedded device 1 may be connected to the network by the communication board. For example, the communication board may be connected to a LAN (local area network), a wireless LAN, the Internet, a WAN (wide area network), or the like.

  The secondary storage device 121 stores a window system, a program group, and a file group in addition to the initial boot OS binary 122, the booted OS binary 123, and the like. Application programs in the program group are executed by the CPUs 101 and 102, the OSs 300 and 400, and the window system.

In the file group, the result of the processing described in the above description as “determination of”, “calculation of”, “comparison of”, “evaluation of”, “update of”, etc. is shown. Information, data, signal values, variable values, and parameters are stored as items of “˜file” and “˜database”. The “˜file” and “˜database” are stored in a recording medium such as a disk or a memory. Information, data, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPUs 101 and 102 via a read / write circuit, and extracted, searched, referenced, and Used for CPU operations such as comparison, calculation, calculation, processing, editing, output, printing, and display. Information, data, signal values, variable values, and parameters are stored in the main memory, registers, cache memory, and buffers during the CPU operations of extraction, search, reference, comparison, calculation, processing, editing, output, printing, and display. It is temporarily stored in a memory or the like.
Also, the arrows in the flowchart described above mainly indicate input / output of data and signals, and the data and signal values are recorded in the memory 111, the secondary storage device 121, and other recording media. Data and signals are transmitted online via buses, signal lines, cables and other transmission media.

  In the description of the first to eighth embodiments, what is described as “to means” may be “to circuit”, “to device”, “to device”, and “to part”. Also, “˜step”, “˜procedure”, and “˜processing” may be used. That is, what is described as “to means” may be realized by firmware as shown in FIG. 1, FIG. 9, FIG. 16, FIG. 25, FIG. It may be. Alternatively, only hardware such as elements, devices, substrates, and wirings, or a combination of software and hardware, or a combination of firmware may be used. Firmware and software are stored as programs in a recording medium such as a ROM (Read Only Memory), a magnetic disk, a flexible disk, an optical disk, a compact disk, a mini disk, and a DVD. The program is read by the CPUs 101 and 102 and executed by the CPUs 101 and 102. In other words, the program causes the computer to function as “means” in the first to eighth embodiments. Alternatively, the computer executes the procedures and methods of “means” in the first to eighth embodiments.

  As described above, the embedded devices shown in the first to eighth embodiments include a CPU as a processing device, a memory as a storage device, a secondary storage device, a keyboard as an input device, a mouse, a communication board, and the like, a display device as an output device, and a communication board. As described above, the function indicated as “means” is realized by using these processing devices, storage devices, input devices, and output devices.

FIG. 3 illustrates a configuration example of an embedded device according to Embodiment 1. FIG. 5 is a diagram showing an example of the contents of an initial boot OS boot information table according to the first embodiment. FIG. 3 is a diagram illustrating an example of contents of a hardware management table according to the first embodiment. FIG. 3 is a diagram illustrating an example of the contents of a booted OS hardware information table according to the first embodiment. FIG. 4 shows an example of the contents of a memory area division table according to the first embodiment. FIG. 5 is a diagram showing an example of contents of an OS activation information table according to the first embodiment. FIG. 3 is a flowchart showing an operation example until the embedded device according to Embodiment 1 operates normally. FIG. 5 is a flowchart showing an operation example until the initial boot OS starts the booted OS in the normal operation state according to the first embodiment. FIG. 6 illustrates a configuration example of an embedded device according to a second embodiment. FIG. 10 is a diagram illustrating a description example of a booted OS boot user setting file according to the second embodiment. FIG. 10 is a flowchart showing an operation example until the initial boot OS starts the booted OS in the normal operation state according to the second embodiment. FIG. 10 is a diagram illustrating an example of contents of a hardware management table according to the third embodiment. FIG. 10 is a flowchart showing an operation example until a built-in device according to Embodiment 3 operates normally. FIG. 10 is a flowchart showing an operation example until the initial boot OS starts the booted OS in the normal operation state according to the third embodiment. The figure which shows the structural example of the conventional embedded apparatus. FIG. 6 illustrates a configuration example of an embedded device according to a fourth embodiment. FIG. 10 shows an example of the contents of a memory area division table according to the fourth embodiment. The figure which shows the example of the content of the user setting file for starting OS400 which concerns on Embodiment 4. FIG. The figure which shows the example of the content of the user setting file for starting OS600 which concerns on Embodiment 4. FIG. FIG. 10 shows an example of the contents of a booted OS hardware information table according to the fourth embodiment. FIG. 10 is a flowchart showing an operation example from a hardware reset to an initial startup OS being started according to the fourth embodiment. FIG. 10 is a flowchart showing an operation example when the initial boot OS 300 according to the fourth embodiment starts the booted OS 400; The figure which shows the example of the content of the hardware management table after the initial starting OS300 and to-be-started OS400 which concern on Embodiment 4 operate | move. FIG. 10 is a flowchart showing an operation example until the initial boot OS 300 according to the fourth embodiment starts the booted OS 600. FIG. 9 shows a configuration example of an embedded device according to a fifth embodiment. FIG. 20 is a diagram showing an example of user setting file description for adding hardware of the initial startup OS according to the fifth embodiment. FIG. 10 is a flowchart showing an operation example for adding hardware to the initial boot OS according to the fifth embodiment. FIG. 10 illustrates a configuration example of an embedded device according to a sixth embodiment. FIG. 20 shows an example of a description of a user setting file for deleting a booted OS hardware according to the sixth embodiment. FIG. 10 is a flowchart showing an operation example for deleting hardware from a booted OS according to the sixth embodiment. FIG. 10 illustrates a configuration example of an embedded device according to a seventh embodiment. FIG. 20 shows a priority calculation example according to the seventh embodiment. FIG. 20 is a diagram illustrating an example of contents of a priority management table according to the seventh embodiment. FIG. 20 is a diagram illustrating an example of the contents of a hardware management table according to the seventh embodiment. FIG. 20 shows an example of the contents of a booted OS boot user setting file according to the seventh embodiment. FIG. 18 is a flowchart showing an operation example of the embedded device according to the seventh embodiment. FIG. 20 shows an example of the contents of a priority management table according to the eighth embodiment. FIG. 19 is a flowchart showing an operation example of the embedded device according to the eighth embodiment.

Explanation of symbols

  1 embedded device, 100 hardware, 101 CPU, 102 CPU, 103 CPU, 104 CPU, 105 CPU, 111 memory, 121 secondary storage device, 122 initial boot OS binary, 123 boot OS binary, 124 boot OS startup User setting file, 125 booted OS binary, 126 booted OS boot user setting file, 127 initial boot OS hardware addition user setting file, 128 booted OS hardware deletion user setting file, 129 booted OS binary, 130 Booted OS boot user setting file, 131 I / O device, 200 firmware, 201 OS boot means, 202 initial boot OS boot means, 203 hardware management means, 251 initial boot OS boot information table, 2 2 hardware management table, 253 hardware information table for OS to be started, 254 memory area division table, 255 user setting hardware information table, 256 priority management table, 300 initial boot OS, 301 hardware allocation means, 302 hardware Start / stop means, 304 User setting hardware information creation means, 351 Priority setting table, 400 OS to be started, 401 Hardware start / stop means, 402 Hardware allocation means, 404 User setting hardware information creation means, 451 Priority Degree setting table, 500 OS boot information table, 600 booted OS, 601 hardware start / stop means, 602 hardware allocation means, 651 priority setting table, 700 booted OS, 70 Hardware start / stop means.

Claims (22)

An information processing apparatus having a plurality of OSs (Operating Systems) and hardware resources allocated to the plurality of OSs,
Hardware management means for managing the allocation status of hardware resources and notifying the allocation status of hardware resources when activation of any OS is requested;
When activation of any OS is requested, the hardware resources necessary for activation are referred to the activation hardware resource information indicated for each OS, and are necessary for activation of the booted OS requested to be activated. Hardware resources are determined, hardware resource allocation status is notified from the hardware management means, and hardware resource allocation status notified from the hardware management means and hardware resources required for booting the booted OS Hardware allocation means for selecting a hardware resource to be allocated to the booted OS based on the above, and allocating the selected hardware resource to the booted OS;
An information processing apparatus comprising: an OS activation unit that activates a booted OS using the hardware resource allocated by the hardware allocation unit. The hardware allocating means is
When an initial startup OS that is started first among the plurality of OSs is started and the initial startup OS enters a normal operation state, startup of any other OS is requested, and startup is requested. The information processing apparatus according to claim 1, wherein a hardware resource to be allocated to the booted OS is selected, and the selected hardware resource is allocated to the booted OS. The hardware management means includes
Manage hardware allocation status information indicating the allocation status of hardware resources,
2. The information according to claim 1, wherein after the hardware resources are allocated to the booted OS by the hardware allocation unit, the hardware allocation status information is updated to reflect the allocation of the hardware resources to the booted OS. Processing equipment. The information processing apparatus includes:
The hardware startup means is included in an initial startup OS that is started first among a plurality of OSs,
The information processing apparatus according to claim 1, wherein the initial boot OS allocates hardware resources by the hardware allocation unit to a booted OS that is requested to start after starting itself. The information processing apparatus includes:
Each OS includes the hardware allocation means,
2. The information processing apparatus according to claim 1, wherein each OS allocates hardware resources by the hardware allocation unit to an OS to be activated that is requested to be activated after it is activated. The information processing apparatus further includes:
The requested hardware resource information in which the requested hardware resource requested to be allocated is shown for each OS is compared with the activated hardware resource information, and the activated OS is activated by the requested hardware resource of the activated OS. A hardware resource judging means for judging whether or not it is possible;
The hardware allocating means is
When it is determined by the hardware resource determining means that the booted OS can be booted with the requested hardware resource of the booted OS, the allocation status of the hardware resource notified from the hardware management means and Based on the requested hardware resources of the booting OS
The information processing apparatus according to claim 1, wherein a hardware resource assigned to S is selected. The hardware management means includes
Manages the allocation status of hardware resources and the usage status of hardware resources, and notifies the allocation status of hardware resources and the usage status of hardware resources when activation of any OS is requested,
The hardware allocating means is
The hardware management means is notified of the allocation status of hardware resources and the usage status of hardware resources, and the allocation status of hardware resources, the usage status of hardware resources, and the OS to be started notified from the hardware management means. The information processing apparatus according to claim 1, wherein a hardware resource to be allocated to the booted OS is selected based on a hardware resource necessary for booting. The hardware allocating means is
8. The information processing apparatus according to claim 7, wherein a hardware resource that has already been assigned to another but is not currently used is selected as a hardware resource to be assigned to the booted OS. The information processing apparatus includes:
The information processing apparatus according to claim 1, wherein the information processing apparatus is an embedded device having a multi-core CPU (Central Processing Unit) configuration. An OS activation method for activating an OS in an information processing apparatus having a plurality of OSs (Operating Systems) and having hardware resources allocated to the plurality of OSs,
A hardware management step for managing the allocation status of hardware resources and notifying the allocation status of hardware resources when activation of any OS is requested;
When activation of any OS is requested, the hardware resources necessary for activation are referred to the activation hardware resource information indicated for each OS, and are necessary for activation of the booted OS requested to be activated. Hardware resources are determined, hardware resource allocation status is notified from the hardware management step, hardware resource allocation status notified from the hardware management step, and hardware resources required for booting the booted OS A hardware allocation step of selecting a hardware resource to be allocated to the booted OS based on the above, and allocating the selected hardware resource to the booted OS;
An OS booting method comprising: an OS booting step of booting a booted OS using the hardware resource allocated in the hardware allocation step. A computer having a plurality of OSs (Operating Systems) and hardware resources allocated to the plurality of OSs.
A hardware management process for managing the allocation status of hardware resources and notifying the allocation status of hardware resources when activation of any OS is requested;
When activation of any OS is requested, the hardware resources necessary for activation are referred to the activation hardware resource information indicated for each OS, and are necessary for activation of the booted OS requested to be activated. Hardware resources are determined, hardware resource allocation status is notified from the hardware management processing, and hardware resource allocation status notified from the hardware management processing and hardware resources necessary for booting the booted OS Hardware allocation processing to select a hardware resource to be allocated to the booted OS based on the above, and to allocate the selected hardware resource to the booted OS;
A program for executing an OS boot process for booting a booted OS using the hardware resource allocated by the hardware allocation process. The hardware allocating means is
When there is at least one activated OS that has already been activated when the activation of the activated OS is requested, the usage status of the hardware resources allocated to the activated OS in the activated OS is Inquires the hardware management means, selects a hardware resource to be allocated to the booted OS based on a response from the hardware management means,
The hardware management means includes
In response to an inquiry from the hardware allocating unit, the usage status of the allocated hardware resource in the booted OS is investigated, and a response indicating the investigation result is sent to the hardware allocating unit. The information processing apparatus according to claim 1. The hardware allocating means is
As a result of comparing the allocation status of the hardware resources notified from the hardware management means and the hardware resources necessary for booting the booted OS, at least a part of the hardware resources necessary for booting the booted OS 13. The information processing apparatus according to claim 12, wherein when it is determined that cannot be allocated, the hardware management unit is inquired about a usage status of the allocated hardware resource in the activated OS. The hardware allocating means is
When a hardware resource necessary for starting the booted OS is not used in the booted OS, a hardware resource that is not used in the booted OS is selected as a hardware resource to be allocated to the booted OS. The information processing apparatus according to claim 12. The information processing apparatus further includes:
Hardware addition instruction means for instructing the hardware assignment means to additionally assign a specific type of hardware resource to a specific activated OS that has already been activated;
The hardware allocating means is
When there is an instruction to add the specific type of hardware resource to the specific booted OS from the hardware addition instruction means, and there is a booted OS other than the specific booted OS Inquiring of the hardware management means about the usage status of the hardware resources allocated to other activated OSs other than the specific activated OS in the other activated OS, and based on the response from the hardware managing means Select a hardware resource to be additionally allocated to the specific booted OS,
The hardware management means includes
In response to an inquiry from the hardware allocation unit, the usage status of the allocated hardware resource in the other booted OS is investigated, and a response indicating the investigation result is sent to the hardware allocation unit. The information processing apparatus according to claim 1. The hardware allocating means is
When the specific type of hardware resource is not used in the other booted OS, the specific type of hardware resource that is not used in the other booted OS is additionally allocated to the specific booted OS. The information processing apparatus according to claim 15, wherein the information processing apparatus is selected as a hardware resource that performs the processing. The information processing apparatus further includes:
Whether the specific booted OS can continue to operate even if the allocation of a specific type of hardware resource from the specific booted OS that has already been booted is released, determines whether the boot hardware of the specific booted OS If the specific booted OS can continue to operate even if the allocation of the specific type of hardware resource is released by making a determination with reference to the resource information, the specific startup is performed with respect to the hardware allocation unit. Hardware release instructing means for instructing to release the allocation of the specific type of hardware resources in the completed OS,
The hardware allocating means is
2. The information processing apparatus according to claim 1, wherein the allocation of the specific type of hardware resources in the specific activated OS is canceled in accordance with an instruction from the hardware release instruction means. The hardware allocating means is
When it is determined that a plurality of hardware resources of the same kind are not used in at least one booted OS, and the plurality of hardware resources of the same kind are hardware resources necessary for booting the booted OS, 13. The information processing apparatus according to claim 12, wherein one of the plurality of hardware resources of the same type is allocated to the booted OS based on a priority for each of the plurality of hardware resources of the same type. . The information processing apparatus further includes:
In accordance with the inquiry from the hardware allocation means, the priority of the booted OS to which each of the plurality of similar hardware resources is allocated and the task to which each of the plurality of similar hardware resources is allocated Using priority determination means for determining a priority for each of the plurality of hardware resources of the same type using at least one of the priorities;
The hardware allocating means is
19. The information processing apparatus according to claim 18, wherein any one of the plurality of hardware resources of the same type is allocated to the booted OS based on the priority determination by the priority determination unit. The hardware allocating means is
When there is no free space for a specific type of hardware resource in any of the activated OSs, any one of the specific types of the specific type is determined based on the priority for the specific type of hardware resources assigned to each activated OS. The information processing apparatus according to claim 12, wherein hardware resources are allocated to the booted OS. The information processing apparatus further includes:
In accordance with the inquiry from the hardware allocating means, whether or not the continuous operation is possible even if the allocation of the specific type of hardware resource is released for each activated OS, and the activated hardware resource information of each activated OS. A priority determination unit that determines the priority for the specific type of hardware resource assigned to the activated OS that can be determined by referring to the activated OS;
The hardware allocating means is
21. The information processing apparatus according to claim 20, wherein one of the specific types of hardware resources is allocated to the booted OS based on the priority determination by the priority determination unit. The priority determination means includes
Priority for each of the specific types of hardware resources using at least one of the priority of each activated OS and the priority of the task to which the specific type of hardware resource is allocated in each activated OS The information processing apparatus according to claim 21, wherein: