JP2014029739A - Multi-core processor system, control program, and control method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To achieve non-stop update of an OS.SOLUTION: In the case that urgency is low after downloading and static verification of a new boot program are ended (step S1503: low), an old OS (master) 122 determines whether there is core with no process allocated thereto among cores booted by using an old boot program (step S1505). In the case that the old OS (master) 122 determines that there is a core with no process allocated thereto (step S1505: Yes), a hypervisor 121 converts a reference area of the boot program from an old boot program area to a new boot program area (step S1511), and notifies the core with no process allocated thereto of a reboot instruction to designate the converted reference area (step S1512).

Description

  The present invention relates to a multi-core processor system, a control program, and a control method for updating an operating system.

  In the conventional portable terminal, when the operating system (hereinafter referred to as “OS (Operating System)”) is updated, it is necessary to stop the operation of the application during the update period. For this reason, during the update period, the user cannot use the application operation (hereinafter referred to as “function”), so the update is performed during a time period in which the user's use frequency decreases, such as a midnight time period. It was broken. However, unlike a general-purpose computer, an embedded system such as a portable terminal is assumed to continue to operate for 24 hours and 365 days, and the function must be stopped.

  In the server field, two methods for updating without stopping have been proposed. The first is to prepare a standby system in addition to the main system, and perform processing in the standby system during the update of the main system (conventional technology 1) (see, for example, Patent Documents 1 and 2 below). . The second is to operate a virtual machine and operate software including an OS on the virtual machine during the update period (prior art 2).

JP 54-106146 A JP 2003-330744 A

  However, in the case of the prior art 1 and the prior art 2, the embedded system has a problem in that the system scale and cost are increased. On the other hand, if there is no standby system or virtual machine, there is a problem that the function must be stopped during the update because the update cannot be performed.

  As described above, it is assumed that an embedded system such as a portable terminal will continue to operate for 24 hours 365 days. Conventionally, the user cannot use the function during the update period, and the function cannot be used. The problem was that it had to be stopped.

  The present invention provides a multi-core processor system, a control program, and a control method capable of realizing a non-disruptive update of an OS while reducing the system scale and cost in order to solve the above-described problems caused by the prior art. The purpose is to do.

  According to one aspect of the present invention, a multi-core processor system having a plurality of cores, and a storage unit that stores a first boot program executed by the plurality of cores and a boot address accessed by the plurality of cores at the time of booting The first core of the plurality of cores writes a second boot program in a storage area different from the storage area of the first boot program in the storage unit, and stores the second boot program in the first boot program. A reference area to which a second core to which a process is not assigned among the plurality of cores booted based on the reference is rebooted is converted from the storage area of the first boot program to the storage area of the second boot program A multi-core processor system that notifies the second core of a reboot instruction that specifies the converted reference area Arm, provides a control program, and control method.

  According to the present multi-core processor system, control program, and control method, there is an effect that non-stop update of the OS can be realized while reducing the system scale and cost.

It is a block diagram which shows the hardware constitutions of the multi-core processor system concerning embodiment. 2 is a block diagram showing a functional configuration of a multi-core processor system 100. FIG. It is explanatory drawing which shows the download preparation example and download example of a new boot program. It is explanatory drawing which shows the example in which a new boot program area | region is set. It is explanatory drawing which shows the example by which CPU # N is rebooted. FIG. 10 is an explanatory diagram (part 1) illustrating an example of memory access restriction by the hypervisor 121; FIG. 10 is an explanatory diagram (part 2) illustrating an example of memory access restriction by the hypervisor 121; FIG. 10 is an explanatory diagram (part 3) illustrating an example of memory access restriction by the hypervisor 121; FIG. 10 is an explanatory diagram (part 4) illustrating an example of memory access restriction by the hypervisor 121; It is explanatory drawing which shows the example by which new OS was booted by CPU # N. It is explanatory drawing which shows the example of a preparation which boots new OS by CPU # M. It is explanatory drawing which shows the example which all the processes allocated to CPU # M completed. It is explanatory drawing which shows the example by which new OS was booted with all the CPUs. 5 is a flowchart (part 1) illustrating an OS update procedure performed by the multi-core processor system. 6 is a flowchart (part 2) illustrating an OS update procedure performed by the multi-core processor system. 12 is a flowchart illustrating a memory access restriction processing procedure performed by the hypervisor 121. 12 is a flowchart (No. 3) illustrating the OS update procedure by the multi-core processor system.

  Exemplary embodiments of a multicore processor system, a control program, and a control method according to the present invention will be explained below in detail with reference to the accompanying drawings.

(Hardware configuration of multi-core processor system)
FIG. 1 is a block diagram of a hardware configuration of the multi-core processor system according to the embodiment. In FIG. 1, a multi-core processor system 100 includes a CPU (Central Processing Unit) #M, a CPU #N, an arbitration circuit 102, a shared memory 103, a storage 104, and an I / F (InterFace) 105. ing. Each component is connected by a bus 101.

  Here, the multi-core processor is a processor equipped with a plurality of cores. If a plurality of cores are mounted, a single processor having a plurality of cores may be used, or a processor group in which single core processors are arranged in parallel may be used. In the present embodiment, in order to simplify the description, a processor group in which two processors of single core CPU #M and CPU #N are connected in parallel will be described as an example.

  The CPU #M and CPU #N include a core, a cache, a register, and the like that can operate independently. The program stored in the storage 104 is mapped to the shared memory 103 by the CPU #M or CPU #N and loaded, thereby causing the CPU #M or CPU #N to execute the coded processing. .

  The arbitration circuit 102 is a circuit that performs arbitration so that no conflict occurs even when accesses to the shared memory 103 occur simultaneously from different CPUs. The priority information in the arbitration circuit 102 is information indicating the priority for each CPU, and the arbitration circuit 102 arbitrates access to the shared memory 103 based on the priority information. In the present embodiment, there are two stages of whether the priority is high. High priority indicates that the priority is high, and low priority indicates that the priority is not high.

  The shared memory 103 is a memory having a CPU # M local area 110 and a CPU # N local area 111. The shared memory 103 is configured by, for example, a ROM (Read Only Memory), a RAM (Randam Access Memory), and the like. For example, the RAM is used as a work area for CPU #M and CPU #N.

  The storage 104 has an MBR 108, an old boot program storage area (hereinafter referred to as “old boot program area 109”), and a user file system area. The storage 104 is configured by, for example, a flash ROM or a hard disk drive.

  The MBR (Master Boot Record) 108 is a head portion (sector) on the storage 104 that is first read when the CPU #M or CPU #N is activated. The MBR 108 records information such as how to boot which OS stored in the storage 104, and specifically stores a bootstrap loader, a partition table, and a boot signature.

  The bootstrap loader stores a startup program. The partition table shows a start address and an end address where the boot program is stored. The boot signature stores a value of 0xAA55 as an identifier. If 0xAA55 is stored in the boot signature, the MBR 108 is valid. If 0xAA55 is not stored, the MBR 108 is invalid. .

  Here, the boot program is a core program of the OS. For example, in the case of Linux (registered trademark), the core part of the OS is a kernel. The old boot program area 109 is an area in which the old boot program is stored, and the start address and end address of the area are stored in the partition table. The new / old boot programs shown in the present embodiment indicate whether they are stored in the storage 104 first, or whether the version number has been updated.

  When CPU #M (or CPU #N) is activated, MBR 108 is first read, and the processing coded in the activation program stored in the bootstrap loader is executed by CPU #M (or CPU #N). . The bootstrap loader reads the partition table that records the position and size of the partition, and reads the start address of the old boot program of the OS.

  Here, the CPU #M reads the old boot program and maps the read old boot program to the shared memory 103. The area in the shared memory 103 of the old boot program mapped by the CPU #M is the CPU #M local area 110 described above. Then, the CPU #M starts the process coded in the mapped old boot program as the old OS (master) 122.

  On the other hand, the CPU #N reads the old boot program and maps the read old boot program to the shared memory 103. The area in the shared memory 103 of the old boot program mapped by the CPU #N is the CPU #N local area 111 described above. Then, the CPU #N starts the process coded in the mapped old boot program as the old OS (slave) 123 of the master OS.

  The I / F 105 controls an internal interface with the network 106 and controls input / output of data from an external device. For example, a modem or the like can be adopted as the I / F 105. The I / F 105 is connected to a network 106 such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet through a communication line, and is connected to an OS update data distribution source 107 via the network 106.

  Next, the hypervisor 121 is a program that directly operates on hardware such as CPU # M and CPU # N, and is a program stored in a register in the hardware. Although the hypervisor 121 operates independently for each CPU, since all perform the same processing, only the hypervisor 121 is described in FIG.

  For example, in the case of the old boot program deletion process described later, it seems that the old boot program in which only one hypervisor 121 exists is deleted, but the CPU that has reached the earliest process until the deletion process. The hypervisor 121 deletes the file. Therefore, even if the hypervisor 121 of another CPU performs a deletion process later, there is no longer an old boot program to be discarded.

  The hypervisor 121 directly refers to the registers in the CPU #M and CPU #N, reads the information in the registers in the CPU #M and CPU #N, and reads the information in the registers in the CPU #M and CPU #N. Privileged instructions that can be rewritten can be implemented.

  Further, a reboot instruction to the CPU #M and CPU #N is also a privileged instruction of the hypervisor 121. Specifically, the reboot instruction by the hypervisor 121 is to instruct the CPU #M or CPU #N to jump to the start address of the old boot program area 109 described in the partition table. In this embodiment, by instructing CPU #M or CPU #N to jump to the start address of the storage area for the new boot program (hereinafter referred to as “new boot program area”), CPU #M or CPU #N starts the OS with a new boot program.

  The old OS (master) 122 and the old OS (slave) 123 are software that operates on the hypervisor 121. The meaning is different between the master / slave in the OS and the master / slave in the connection relationship between the CPUs. The master OS (in this embodiment, the old OS (master) 122) runs a scheduler that determines process allocation, and the slave OS (in this embodiment, the old OS (slave) 123) executes the process assigned by the scheduler. To do.

  The master OS registers the process allocation result in the task table. Here, the task table is a table of process information managed by a general OS. The boot time, memory resource, process number, name of the booted user, execution conditions (such as the version of the library serviced by the linked OS), and the path of the executable file are described. That is, the CPU #M reads the startup time and execution conditions from the task table by the old OS (master) 122, which OS (assignment) each application (process) is assigned to, and which application (process) has been executed. Can be monitored.

  The update detection application 131 is an application program that runs on the OS, and detects an update of the boot program. The update detection application 131 is allocated on the old OS (master) 122. Further, a main process 133 that is a GUI (Graphic User Interface) process is assigned to the old OS (master) 122.

  The downloader 132 is an application program that runs on the OS, and downloads a boot program and a library. The downloader 132 may operate on any of the old OS (master) 122 and the old OS (slave) 123, but is assigned to the old OS (slave) 123 here.

  The downloader 132 downloads a new boot program from the OS update data distribution source 107 via the I / F 105 and performs static verification. Static verification is to check whether the binary data of the boot program is correct or conforms to a standard. Dynamic verification is to check whether a new boot program can be normally booted.

(Functional configuration of multi-core processor system 100)
FIG. 2 is a block diagram showing a functional configuration of the multi-core processor system 100. The hypervisor 121 activated in the multi-core processor system 100 includes a setting unit 201, a reception unit 202, a determination unit 203, a conversion unit 204, a notification unit 205, a detection unit 206, and a deletion unit 207. It is the composition which includes. As described above, since the hypervisor 121 is a program including a notification program, the CPU (#M) and the CPU (#N) cause the hypervisor 121 stored in the storage 104 or the ROM in the shared memory 103 to execute each function ( A deletion unit 207) is realized from the setting unit 201.

  First, upon receiving an instruction to update a new boot program, the setting unit 201 sets a new boot program area based on the old boot program area 109 and a predetermined mask value.

  Next, after the new boot program area is set by the setting unit 201, the receiving unit 202 receives an input of access to the old boot program area 109 related to downloading of the new boot program.

  The determination unit 203 determines whether the access received by the reception unit 202 is a write access or a read access.

  When the determination unit 203 determines that the access is a write access, the conversion unit 204 converts the address specified by the write access into an address specifying a new program area based on the predetermined mask value.

  When the access is a read access, the notification unit 205 notifies an access instruction to the address specified by the read access to the access source of the read access. On the other hand, when the access is a write access, the notification unit 205 notifies the access source of the write access of an access instruction to the address after conversion by the conversion unit 204. Next, processing after the new boot program is downloaded will be described.

  The detection unit 206 detects a CPU to which no process is assigned among CPUs booted using an old boot program among multi-core processors. In this embodiment, as will be described later, the OS detects a core to which no process is assigned, and notifies the hypervisor 121 that a process has not been assigned to the detected core. Then, the hypervisor 121 is assumed to detect a core to which no process is assigned to accept this notification.

  When the detecting unit 206 detects a CPU to which no process is assigned, the converting unit 204 converts the reference area from the old boot program area 109 to the new boot program storage area.

  The notification unit 205 notifies the CPU that has completed the reboot instruction for designating the reference area after conversion by the conversion unit 204.

  In addition, when a CPU to which no process is assigned is not detected, the detection unit 206 detects a CPU in which operations of all assigned processes have been completed.

  When the detecting unit 206 detects the completed CPU, the converting unit 204 converts the reference area from the old boot program area 109 to the new boot program area. The notification unit 205 notifies the CPU that has completed the reboot instruction for designating the reference area after conversion by the conversion unit 204.

  When the notification unit 205 is notified of the reboot instruction, the conversion unit 204 designates the new boot program area based on a predetermined mask value with the address that designates the old boot program area 109 stored in the master boot record of the storage device To the address you want.

  When the conversion unit 204 changes the old boot program area 109 stored in the master boot record of the storage device, the deletion unit 207 deletes the old boot program stored in the old boot program area 109.

  Based on the above, detailed operations of the multi-core processor system 100 will be described with reference to the drawings.

  FIG. 3 is an explanatory diagram illustrating a download preparation example and a download example of a new boot program. First, the update detection application 131 detects an update to the boot program via the I / F, and (1) notifies the old OS (master) 122 of the update of the boot program. Next, when the old OS (master) 122 receives the update of the boot program, (2) notifies the hypervisor 121 of the update of the boot program. When the hypervisor 121 receives the update of the new boot program, (3) the new boot program area 112 is set based on a predetermined mask value and the area of the old boot program.

  FIG. 4 is an explanatory diagram showing an example in which the new boot program area 112 is set. Here, a detailed example of (3) setting of a new boot program area will be described. The hypervisor 121 refers to the partition table 401 of the MBR 108 and acquires the start address and end address of the old boot program area 109. The hypervisor 121 calculates the start address of the new boot program area 112 by taking the logical sum of the start address of the old boot program area 109 and the mask value.

  The hypervisor 121 calculates the end address of the new boot program area 112 by calculating the logical sum of the end address of the old boot program area 109 and the mask value. The hypervisor 121 reserves the area from the area indicated by the calculated start address of the new boot program in the storage 104 to the area indicated by the calculated end address of the new boot program as the area of the new boot program.

  Returning to FIG. 3, (4) the hypervisor 121 notifies the old OS (master) 122 of a download start instruction, and monitors access to the new boot program downloader 132 and the old boot program related to static verification. When the old OS (master) 122 accepts the download start notification, (5) notifies the downloader 132 of the download start instruction. When the downloader 132 receives a download start instruction, the downloader 132 downloads a new boot program from the update data distribution source 107 of the OS via the I / F 105.

  Then, during the download of the new boot program, the downloader 132 inputs (6) access to the old boot program to the old OS (slave) 123 in order to perform write access to the old boot program. When the old OS (slave) 123 receives access to the old boot program related to downloading of the new boot program, (7) the access is input to the hypervisor 121.

  When the hypervisor 121 receives access to the old boot program related to downloading of the new boot program, the hypervisor 121 determines whether the access is a write access or a read access. When the hypervisor 121 determines that the access is a write access, the address indicated by the write access is converted to an address that designates the new boot program area 112 based on a predetermined mask value.

  Then, the hypervisor 121 (8) notifies the old OS (slave) 123 of an instruction to access the converted address. On the other hand, when the hypervisor 121 determines that the access is a read access, the access instruction to the address designated by the read access is notified to the old OS (slave) 123.

  An address designated by access is set to 0x1110, and a predetermined mask value is set to 0x1000. For example, in the case of read access, the hypervisor 121 notifies the old OS (slave) 123 of an access instruction to 0x1110. For example, in the case of write access, the hypervisor 121 calculates a logical sum of 0x1110 and 0x1000 (the following formula (1)) to convert the address to the new boot program area 112. Then, the access instruction to the converted address is notified to the old OS (slave) 123.

Address specifying the boot program area = 0x1110 + 0x1000
= 0x0110 (1)

  Here, “+” indicates a logical sum. Therefore, the hypervisor 121 notifies the old OS (slave) 123 of an access instruction to 0x0110.

  When the old OS (slave) 123 receives an access instruction from the hypervisor 121, (9) notifies the downloader 132 of the access instruction. Since FIG. 3 shows write access, the downloader 132 executes (10) access to the address after conversion.

  FIG. 5 is an explanatory diagram illustrating an example in which the CPU #N is rebooted. After downloading the new boot program to the new boot program area 112, the update detection application 131 notifies the old OS (master) 122 of (11) update condition information. The update condition information includes execution constraint, target version number, update execution CPU number, and urgency information. The information on the urgency level is information regarding whether or not the urgency level is high.

  When the old OS (master) 122 receives the update condition information, the old OS (master) 122 reads the urgency level information from the received update condition information. If the read urgency level information indicates that the urgency level is high, the old OS (master) 122 uses the task table. The process assigned to the update execution CPU is specified, and (12) forced migration is performed. Here, process 134 is identified. The process 134 assigned to the update execution CPU by the forced migration is assigned to the CPU #M.

  Here, the update execution CPU is CPU # N. The update execution CPU is a CPU that reboots with a new boot program prior to other CPUs. The method for determining the update execution CPU is not particularly limited because at least a master OS capable of assigning a process to the old OS may be rebooted last in the old OS.

  For example, when a multi-core processor is configured by four CPUs, two CPUs from the remaining CPUs excluding the CPU that executes the processing of the master OS are set as update execution CPUs. The CPU that executes the process of the master OS and another CPU may be replaced with the CPU that is rebooted after the update execution CPU reboots. Further, all the remaining CPUs other than the CPU that executes the process of the master OS may be the update execution CPU.

  When the read urgency level information indicates that the urgency level is not high (the urgency level is low), the old OS (master) 122 is one of the CPUs other than the CPU that operates the master OS among the multi-core processors. A CPU to which no process is assigned is detected. Since a process is assigned to CPU #N, a CPU to which no process is assigned is not detected. Next, the old OS (master) 122 prohibits dispatching to the CPU #N, and detects that the process assigned to the CPU #N is terminated.

  Then, when there is no process assigned to CPU #N due to forced migration or process termination, (13) the process that old OS (master) 122 has been assigned to CPU #N is completed (or updated) The execution CPU may be used) and a memory access restriction instruction is notified to the hypervisor 121. When the hypervisor 121 receives the notification, (14) the access restriction of the shared memory 103 is started. When the hypervisor 121 starts to restrict access to the shared memory 103, for example, each OS or application cannot access the shared memory 103 until an access instruction from the hypervisor 121 is received.

  Then, after the hypervisor 121 starts to restrict access to the shared memory 103, the boot program reference area is converted from the old boot program area 109 to the new boot program area 112, and (15) the converted reference area is designated. A reboot instruction is notified to the old OS (slave) 123. When the old OS (slave) 123 receives the reboot instruction, the old OS (slave) 123 starts the reboot with reference to the new boot program (16). Also, one of the update target CPUs reboots with the new OS as the master OS. Since only the CPU #N is used here, the CPU #N reboots with the new OS as the master OS. Next, memory access restriction by the hypervisor 121 will be described with reference to FIGS.

  FIG. 6 is an explanatory diagram (part 1) illustrating an example of memory access restriction by the hypervisor 121. In the figure, (17) a case where an access to the CPU # M local area 110 in the shared memory 103 occurs from the old OS being rebooted will be described. When the hypervisor 121 starts the memory access restriction, the hypervisor 121 detects all accesses to the shared memory 103 from the application and access addresses.

  The hypervisor 121 (18) detects the access to the CPU #M local area 110 in the shared memory 103 and the access address from the old OS being rebooted. The hypervisor 121 determines whether or not the access is from the CPU #N. Here, since the access is from the old OS (slave) 123, it is determined that the access is from the CPU #N. Subsequently, the hypervisor 121 makes a determination based on the address of the access that has detected whether or not it is an access to the local area of another CPU.

  Here, it is determined that the detected access is an access to the CPU #M local area 110, and (19) the hypervisor 121 outputs an update failure of the old OS (slave) 123 or the downloaded new boot program is invalid. Is output. Examples of the output format include display on a display and transmission to an external device via the I / F 105. Further, it may be stored in an area other than the local area of each CPU in the shared memory 103.

  Access from the CPU #N being booted to the CPU #M local area 110, which is the work area of the CPU #M, does not occur if it is a normal boot program. Therefore, it is possible to prevent updating with an abnormal boot program according to (17) to (19).

  FIG. 7 is an explanatory diagram (part 2) of an example of memory access restriction by the hypervisor 121. In FIG. 7, (20) a case where an access to the CPU #N local area 111 in the shared memory 103 occurs from the old OS being rebooted will be described.

  The hypervisor 121 (21) detects access to the CPU #N local area 111 in the shared memory 103 from the old OS being rebooted. The hypervisor 121 determines whether or not the access is from the CPU #N. Here, since the access is from the old OS (slave) 123, it is determined that the access is from the CPU #N. Subsequently, the determination is made based on the address designated by the access in which the hypervisor 121 detects whether the access is to the local area of another CPU.

  Here, it is determined that the detected access is access to the CPU #N local area 111, and the hypervisor 121 sets (22) priority information regarding the CPU #N in the arbitration circuit 102 to low priority. Then, the hypervisor 121 notifies an access instruction.

  The CPU #N that is booting initializes various tables, updates system files, temporarily saves and restores system files, and flushes cache data associated with the temporary save and restore. That is, the CPU #N that is booting has more access to the shared memory 103 than the CPU #M that is operating a normal application.

  As described above, the priority information regarding the CPU #N in the arbitration circuit 102 is set to low priority, so that memory contention (contention for memory access right) can be prevented. Then, the OS can be updated without affecting applications running on the CPU #M that is not booting.

  FIG. 8 is an explanatory diagram (part 3) illustrating an example of memory access restriction by the hypervisor 121. In FIG. 8, (23) a case where an access from the old OS (master) 122 to the CPU # M local area 110 in the shared memory 103 occurs will be described.

  The hypervisor 121 detects (24) access from the old OS (master) 122 to the CPU # M local area 110 in the shared memory 103. It is determined whether or not the access detected by the hypervisor 121 is an access from the CPU #N. Here, since the access is from the old OS (master) 122, it is determined that the access is not from the CPU #N. Subsequently, the determination is made based on the address indicated by the access in which the hypervisor 121 detects whether or not it is an access to the local area of another CPU.

  Here, it is determined that the detected access is access to the CPU # M local area 110, and the hypervisor 121 sets (25) priority information regarding the CPU # N in the arbitration circuit 102 to low priority. Then, the hypervisor 121 notifies the old OS (master) 122 of an access instruction.

  FIG. 9 is an explanatory diagram (part 4) illustrating an example of memory access restriction by the hypervisor 121. In FIG. 9, (26) a case where an access from the old OS (master) 122 to the CPU #N local area 111 in the shared memory 103 occurs will be described.

  The hypervisor 121 detects (27) an access from the old OS (master) 122 to the CPU #N local area 111 in the shared memory 103. It is determined whether or not the access detected by the hypervisor 121 is an access from the CPU #N. Here, since the access is from the old OS (master) 122, it is determined that the access is not from the CPU #N. Subsequently, the hypervisor 121 determines based on the address indicated by the detected access whether or not it is an access to the local area of another CPU in the shared memory 103.

  Here, it is determined that the detected access is an access to the CPU #N local area 111, and the hypervisor 121 outputs (28) an access error. Examples of the output format include display on a display and transmission to an external device via the I / F 105. Further, it may be stored in an area other than the local area of each CPU in the shared memory 103.

  FIG. 10 is an explanatory diagram illustrating an example in which the new OS is booted by the CPU #N. In FIG. 10, the new OS (master) 124 is booted as the master OS in CPU #N. Here, a master OS exists for each new OS and old OS. The newly assigned new boot process 136 is scheduled and executed by the new OS (master) 124, so that there is no contention even if the old and new master OSs coexist in the multi-core processor system 100. The process 135 is a process assigned to the old OS (master) 122 during booting of the old OS (slave) 123.

  When the new OS (master) 124 is booted by the CPU #N, the hypervisor 121 releases (29) the memory access restriction, and (30) restores the priority information in the arbitration circuit 102 to the original state. For example, the priority information in the arbitration circuit 102 is copied and stored in the shared memory 103 immediately before the start of the memory restriction, and the priority information in the arbitration circuit 102 is changed using the copied priority information after the memory restriction is released. Restore the priority information.

  FIG. 11 is an explanatory diagram showing a preparation example for booting the new OS by the CPU #M. The old OS (master) 122 identifies the process assigned to the old OS (master) 122 based on the process table. Among the specified processes, processes that are dynamically linked or opened to the old boot program continue processing in the old OS (master) 122. On the other hand, (31) the old OS (master) 122 replaces the processes (in this case, the main process 133 and the update detection application 131) that are not dynamically linked to the old boot program among the specified processes with the new OS (master) 124. Migrate to

  FIG. 12 is an explanatory diagram illustrating an example in which all processes assigned to the CPU #M are completed. In FIG. 12, the process of the process assigned to the old OS (master) 122 is completed. That is, the process assigned to the old OS (master) 122 by the old OS (master) 122 is not specified. Then, (32) the old OS (master) 122 notifies the hypervisor 121 that all processes assigned to the old OS (master) 122 have been completed.

  (33) When the hypervisor 121 receives the notification, the boot program reference area indicated by the partition table 401 stored in the MBR 108 is converted into the new boot program area 112. Then, (34) the hypervisor 121 notifies the old OS (master) 122 of a reboot instruction. Since the boot program reference area indicated by the partition table 401 has already been converted, (35) upon receiving a reboot instruction, the old OS (master) 122 starts rebooting with the new boot program. Here, the old OS (master) 122 is booted as a new OS (slave) 125. (36) The hypervisor 121 discards the old boot program.

  FIG. 13 is an explanatory diagram showing an example in which the new OS is booted by all the CPUs. In FIG. 13, the old OS (master) 122 is activated as the new OS (slave) 125. Furthermore, the area of the old boot program in the storage 104 is vacant.

(OS update procedure by multi-core processor system)
FIG. 14 is a flowchart (part 1) illustrating the OS update procedure by the multi-core processor system 100. Here, a description will be given of processing procedures before the download start, download and static verification by the hypervisor 121, the old OS (master) 122, the downloader 132, and the update detection application 131. First, the update detection application 131 detects an update of the boot program (step S1401). When the update detection application 131 detects an update of the boot program, the update detection application 131 notifies the old OS (master) 122 of the update of the boot program (step S1402). ). When the old OS (master) 122 receives the update of the boot program, it notifies the hypervisor 121 of the update of the boot program (step S1403).

  When the hypervisor 121 receives the update of the boot program, the hypervisor 121 sets a new boot program area based on the old boot program and a predetermined mask value, and notifies the old OS (master) 122 of a download start instruction (step S1404). Then, the hypervisor 121 monitors access related to the boot program to the boot program area (step S1405). Access monitoring refers to the processing from step S1409 to step S1411.

  When the old OS (master) 122 receives a download start instruction from the hypervisor 121, the old OS (master) 122 notifies the downloader 132 of the download start instruction (step S1406). When the downloader 132 receives the download start instruction, the downloader 132 starts download and static verification (step S1407). When the downloader 132 accesses the storage during downloading or static verification, when the OS that operates the downloader 132 inputs access to the old OS (master) 122 and receives access to the storage, the hypervisor 121 is accessed. Access is input to (step S1408).

  When the hypervisor 121 receives an access input, the hypervisor 121 determines whether the received access is a write access or a read access (step S1409). When the hypervisor 121 determines that the access is a write access (step S1409: write access), the hypervisor 121 converts the address specified by the write access based on a predetermined mask value (step S1410). Then, the hypervisor 121 notifies the OS that operates the downloader 132 of an access instruction to the converted address (step S1411).

  On the other hand, when the hypervisor 121 determines that the access is a read access (step S1409: read access), the hypervisor 121 notifies an access instruction to an address designated by the read access (step S1411). Following the step S1411, when the OS that operates the downloader 132 accepts an access instruction, the access instruction is notified to the downloader 132 (step S1412). When the downloader 132 accepts the access instruction, it accesses the storage (step S1413). An arrow between step S1407 and step S1413 indicates that download and static verification are continued according to the access result.

  FIG. 15 is a flowchart (part 2) illustrating the OS update procedure by the multi-core processor system 100. Here, a processing procedure from the download and static verification by the hypervisor 121, the old OS (master) 122, and the downloader 132 until the reboot of the update execution CPU is completed will be described. It is assumed that the update execution CPU does not include the old OS (master) 122. First, when the downloader 132 completes downloading and static verification (step S1501), it notifies update condition information (step S1502).

  When the old OS (master) 122 receives the update condition information, the urgency level is read from the update condition information and the urgency level is determined (step S1503). When the degree of urgency is high (step S1503: high), the old OS (master) 122 forcibly migrates the process assigned to the update execution CPU (step S1504), and proceeds to step S1507.

  On the other hand, when the degree of urgency is low (step S1503: low), the old OS (master) 122 determines whether there is a CPU to which no process is assigned (step S1505). If the old OS (master) 122 determines that there is a CPU to which no process is assigned (step S1505: Yes), the CPU to which no process is assigned is set as the update execution CPU (step S1506), and the step The process moves to S1509. Here, the update execution CPU is only a CPU to which no process is assigned.

  If the old OS (master) 122 determines that there is no CPU to which no process is assigned (step S1505: No), the dispatch to the update execution CPU is prohibited (step S1507). Then, the old OS (master) 122 determines whether or not the process assigned to the update execution CPU has ended (step S1508). When the old OS (master) 122 determines that the process assigned to the update execution CPU has not ended (step S1508: No), the process returns to step S1508.

  On the other hand, when the old OS (master) 122 determines that the process assigned to the update execution CPU has ended (step S1508: Yes), the hypervisor 121 is notified of the access restriction instruction to the shared memory and the update target CPU. (Step S1509).

  When the hypervisor 121 receives an instruction to restrict access to the shared memory and the update target CPU, access restriction is started (step S1510). The access restriction flowchart will be described later. Then, the hypervisor 121 converts the boot program reference area into the new boot program area (step S1511).

  Next, the hypervisor 121 notifies the OS on the update execution CPU of a reboot instruction for designating the converted reference area (step S1512). The OS on the update execution CPU is an OS that causes the update execution CPU to execute processing. Here, any one of the update execution CPUs is instructed to become the master OS when the new boot program is activated. The OS on the update execution CPU reboots when receiving the reboot instruction, and notifies the hypervisor 121 of the completion of the reboot when the reboot is completed (step S1513). When the completion of reboot is accepted from all the CPUs of the update execution CPU, the access restriction of the shared memory is terminated (step S1514), and the priority information in the arbitration circuit is returned to normal (step S1515). Since the priority information in the arbitration circuit is changed due to access restriction, returning the priority information to normal means returning to the priority information before the start of access restriction.

  FIG. 16 is a flowchart showing a memory access restriction processing procedure performed by the hypervisor 121. First, when the hypervisor 121 starts limiting memory access, the hypervisor 121 detects access from the application to the shared memory (step S1601). Next, the hypervisor 121 determines whether or not the access is from the update target CPU (step S1602). Here, the update target CPU is being rebooted. If the hypervisor 121 determines that the access is from the update target CPU (step S1602: Yes), it determines whether the access is to the local area of another CPU (step S1603).

  If the hypervisor 121 determines that the access is to the local area of another CPU (step S1603: Yes), it outputs an update failure (step S1604) and recovers (step S1605). On the other hand, when the hypervisor 121 determines in step S1602 that the access is not from the update target CPU (step S1602: No), it is determined whether the access is to the local area of another CPU (step S1606). When the hypervisor 121 determines that the access is to the local area of another CPU (step 1606: Yes), an access error is output (step S1607).

  On the other hand, when the hypervisor 121 determines that it is not an access to the local area of another CPU (step S1603: No or step S1606: No), the priority information related to the update target CPU in the arbitration circuit is set to low priority. Setting is performed (step S1608). Then, the access instruction is notified to the access source (step S1609). The process is repeated until the hypervisor 121 receives a memory access restriction end instruction.

  FIG. 17 is a flowchart (part 3) illustrating the OS update procedure by the multi-core processor system 100. First, when the new OS is activated, the new OS (master) 124 controls to allocate a new process to the new OS (step S1701). Next, the old OS (master) 122 identifies a process already running on the old OS based on the task table (step S1702).

  Then, the old OS (master) 122 determines whether there is a process already operating on the old OS (step S1703). First, when the old OS (master) 122 determines that there is an already-operated process in the old OS (step S1703: Yes), it determines whether there is an unselected already-processed process (step S1704). When the old OS (master) 122 determines that there is no unselected process already operating (step S1704: No), the process returns to step S1702. On the other hand, when the old OS (master) 122 determines that there is an unselected operation process (step S1704: Yes), an arbitrary process is selected from the unselected operation processes (step S1705).

  Then, the old OS (master) 122 determines whether the selected process is dynamically linked or opened to the system file (step S1706). If the old OS (master) 122 determines that the system file is dynamically linked or opened (step S1706: YES), the process returns to step S1704. On the other hand, when the old OS (master) 122 determines that the system file is not dynamically linked and opened (step S1706: No), the selected process is migrated to the new OS (step S1707), and the process returns to step S1704. .

  On the other hand, when the old OS (master) 122 determines that there is no process already operating on the old OS (step S1703: No), it notifies the hypervisor 121 that there is no process already operating (step S1708). Subsequently, the hypervisor 121 converts the reference area in the partition table to the new boot program area (step S1709), and notifies the old OS of a reboot instruction for specifying the converted reference area (step S1710).

  When the old OS including the old OS (master) 122 receives a reboot instruction, the old OS is rebooted with the new boot program (step S1712). Following step S1710, the hypervisor 121 discards the old boot program (step S1711).

  As described above, according to the multi-core processor system, the control program, and the control method, the reboot instruction for rebooting with the new boot program is notified in order from the core to which no process is assigned among the cores booted with the old boot program. Therefore, the core that has been notified of and received the reboot instruction reboots with the new boot program. As a result, since the system is rebooted immediately from the free core, the OS can be updated without stopping without stopping the process.

  In addition, when there is no core to which no process is assigned, the OS can be updated without stopping the running process by notifying the reboot instruction to reboot the core to which the assigned process has been completed with a new boot program. .

  In addition, the capacity in the storage can be used efficiently by setting a new boot program area in which the new boot program is downloaded after accepting the update of the new boot program.

  Further, after the reboot instruction, the address of the old boot program area in the partition table of the master boot record is converted to the address of the new boot program area. Thereby, even if the power of the CPU rebooted with the new boot program is turned on again, the CPU can boot with the new boot program.

DESCRIPTION OF SYMBOLS 100 Multi-core processor system 201 Setting part 202 Reception part 203 Judgment part 204 Conversion part 205 Notification part 206 Detection part

Claims (6)

With multiple cores,
A multi-core processor system comprising: a first boot program that is executed by the plurality of cores; and a storage unit that stores a boot address that is accessed by the plurality of cores during booting. The core is
In the storage unit, a second boot program is written in a storage area different from the storage area of the first boot program, and a process is not allocated among the plurality of cores booted based on the first boot program. A reference area that the second core refers to at the time of rebooting is converted from the storage area of the first boot program into the storage area of the second boot program, and a reboot instruction that specifies the converted reference area is sent to the second boot program A multi-core processor system that notifies the core.   When the reboot instruction is notified to all of the plurality of cores, the first core uses the boot address based on the storage area of the first boot program based on the storage area of the second boot program. The multi-core processor system according to claim 1, wherein the multi-core processor system is rewritten to an address. A control method for a multi-core processor system, comprising: a plurality of cores; a first boot program that is executed by the plurality of cores; and a storage unit that stores a boot address that the plurality of cores accesses during booting. The first of the cores
A process of writing a second boot program in a storage area different from the storage area of the first boot program in the storage unit;
Of the plurality of cores booted based on the first boot program, a second core to which a process is not assigned refers to a reference area that is referred to at the time of rebooting from the storage area of the first boot program. A process of converting to a program storage area;
And a process of notifying the second core of a reboot instruction specifying the reference area after conversion.   When the first core notifies the reboot instruction to all of the plurality of cores, the boot address based on the storage area of the first boot program is changed to an address based on the storage area of the second boot program. The method of controlling a multi-core processor system according to claim 3, wherein the control method is rewritten as follows. A control program for a multi-core processor system, comprising: a plurality of cores; a first boot program that is executed by the plurality of cores; and a storage unit that stores a boot address that is accessed by the plurality of cores during booting. In the first of the cores,
A process of writing a second boot program in a storage area different from the storage area of the first boot program in the storage unit;
Of the plurality of cores booted based on the first boot program, a second core to which a process is not assigned refers to a reference area that is referred to at the time of rebooting from the storage area of the first boot program. A process of converting to a program storage area;
A control program for a multi-core processor system that executes a process of notifying the second core of a reboot instruction that specifies the reference area after conversion.   When the first core is notified of the reboot instruction to all of the plurality of cores, the boot address based on the storage area of the first boot program is based on the storage area of the second boot program. The control program for a multi-core processor system according to claim 5, wherein the control program is rewritten to an address.

Images