起動時間の異なる複数のオペレーティングシステムOS:OperatingSystemと、複数の前記OSの何れかを選択して演算処理を実行する複数の制御部とを備え、複数の前記制御部のうちの主制御部は、複数の前記OSのうちで起動時間の速い第1のOSを起動して、システム状態を示す動作モードを前記第1のOSに検出させると共に、前記第1のOSによる検出結果に基づいて、前記主制御部とは異なる他の制御部で起動するOSとして、前記第1のOSよりも起動時間の遅い他のOSを選択することを特徴とする電子機器。請求項1に記載の電子機器において、前記他のOSは、汎用OSであって、前記主制御部は、前記検出結果が前記汎用OSを起動する第1動作モードの場合、前記他の制御部で起動する前記汎用OSを選択することを特徴とする電子機器。請求項2に記載の電子機器において、前記汎用OSは、該汎用OSの起動時間を短縮するスナップショットイメージとしてメモリに記録されており、前記他の制御部は、前記スナップショットイメージを起動することを特徴とする電子機器。請求項1に記載の電子機器において、前記他のOSは、タスクの実行時間を管理するリアルタイムOSであって、前記主制御部は、前記検出結果が前記リアルタイムOSを起動する第2の動作モードの場合、前記他の制御部で起動する前記リアルタイムOSを選択することを特徴とする電子機器。請求項1に記載の電子機器において、前記他のOSは、汎用OSとタスクの実行時間を管理するリアルタイムOSとであって、前記主制御部は、前記検出結果が前記汎用OSと前記リアルタイムOSとを起動する第3動作モードの場合、第1の前記他の制御部で起動する前記汎用OSと第2の前記他の制御部で起動する前記リアルタイムOSとを選択することを特徴とする電子機器。請求項1に記載の電子機器において、前記他のOSは、汎用OSであって、前記主制御部は、前記検出結果が前記汎用OSを複数の前記他の制御部で共有して管理する第4動作モードの場合、複数の前記他の制御部で起動する前記汎用OSを選択することを特徴とする電子機器。請求項6に記載の電子機器において、前記第4動作モードは、並列処理方式の対称型マルチプロセッシングSMP:SymmetricMultiprocessingであることを特徴とする電子機器。請求項1から請求項7の何れか1項記載の電子機器において、前記主制御部は、前記第1のOSの起動後、前記他のOSの起動中に中断事由又は中止事由を前記第1のOSが検出した場合、前記他のOSの起動を中断又は中止することを特徴とする電子機器。請求項8に記載の電子機器において、前記主制御部は、前記他のOSの起動中に電源システムの異常状態を前記第1のOSが検出した場合、前記他のOSの起動を中断し、前記主制御部は、前記電源システムの正常状態を前記第1のOSが再度検出した場合、前記他のOSの起動を再開することを特徴とする電子機器。請求項8に記載の電子機器において、前記主制御部は、前記他のOSの起動中に前記動作モードの変更を前記第1のOSが検出した場合、起動中の前記他のOSを強制終了し、前記他の制御部は、前記動作モードに適した変更用の他のOS又は予めメモリに記録されている前記変更用の前記他のOSの起動時間を短縮するスナップショットイメージを起動することを特徴とする電子機器。撮影光学系からの被写体光を撮像して画像を生成する撮像素子と、請求項1から請求項10の何れか1項記載の電子機器と、を備えることを特徴とする電子カメラ。請求項11に記載の電子カメラにおいて、前記主制御部は、前記他のOSの起動中に静止画撮影又は動画撮影の指示入力を検出した場合、前記他のOSの起動を中断し、前記主制御部は、前記静止画撮影又は前記動画撮影の実行後に、前記他のOSの起動を再開することを特徴とする電子カメラ。請求項11又は請求項12に記載の電子カメラにおいて、前記第1のOSは、前記撮影光学系が有するレンズ情報を解析し、前記他の制御部は、前記レンズ情報の解析結果に基づいて、汎用OSとタスクの実行時間を管理するリアルタイムOSとの何れか一方を起動することを特徴とする電子カメラ。ところで、例えばRTOSと汎用OSとを電子カメラ等に搭載した場合、汎用OSが起動を開始してから完了するまでに要する時間が、RTOSに比較して長時間要する。そのため、ユーザは電子カメラの電源をオンした後、汎用OSが起動終了して使用開始状態になるまで待たされるおそれが生じる。すなわち、起動時間の異なる複数のOSの取り扱いが問題となる。そこで、本発明は、上記事情に鑑み、起動時間の異なる複数のOSに関し、複数のOSの起動時間の効率化を図る手段を提供することを目的とする。第1の発明に係る電子機器は、起動時間の異なる複数のOSOperatingSystemと、複数の制御部とを備える。複数の制御部は、複数のOSの何れかを選択して演算処理を実行する。複数の制御部のうちの主制御部は、複数のOSのうちで起動時間の速い第1のOSを起動して、システム状態を示す動作モードを第1のOSに検出させると共に、第1のOSによる検出結果に基づいて、主制御部とは異なる他の制御部で起動するOSとして、第1のOSよりも起動時間の遅い他のOSを選択する。第2の発明は、第1の発明において、他のOSは、汎用OSである。主制御部は、検出結果が汎用OSを起動する第1動作モードの場合、他の制御部で起動する汎用OSを選択する。第3の発明は、第2の発明において、汎用OSは、その汎用OSの起動時間を短縮するスナップショットイメージとしてメモリに記録されている。他の制御部は、スナップショットイメージを起動する。第4の発明は、第1の発明において、他のOSは、タスクの実行時間を管理するリアルタイムOSである。主制御部は、検出結果がリアルタイムOSを起動する第2の動作モードの場合、他の制御部で起動するリアルタイムOSを選択する。第5の発明は、第1の発明において、他のOSは、汎用OSとタスクの実行時間を管理するリアルタイムOSとである。主制御部は、検出結果が汎用OSとリアルタイムOSとを起動する第3動作モードの場合、第1の他の制御部で起動する汎用OSと第2の他の制御部で起動するリアルタイムOSとを選択する。第6の発明は、第1の発明において、他のOSは、汎用OSである。主制御部は、検出結果が汎用OSを複数の他の制御部で共有して管理する第4動作モードの場合、複数の他の制御部で起動する汎用OSを選択する。第7の発明は、第6の発明において、第4動作モードは、並列処理方式の対称型マルチプロセッシングSMP:SymmetricMultiprocessingである。第8の発明は、第1から第7の何れか1の発明において、主制御部は、第1のOSの起動後、他のOSの起動中に中断事由又は中止事由を第1のOSが検出した場合、他のOSの起動を中断又は中止する。第9の発明は、第8の発明において、主制御部は、他のOSの起動中に電源システムの異常状態を第1のOSが検出した場合、他のOSの起動を中断する。主制御部は、電源システムの正常状態を第1のOSが再度検出した場合、他のOSの起動を再開する。第10の発明は、第8の発明において、主制御部は、他のOSの起動中に動作モードの変更を第1のOSが検出した場合、起動中の他のOSを強制終了する。他の制御部は、動作モードに適した変更用の他のOS又は予めメモリに記録されている変更用の他のOSの起動時間を短縮するスナップショットイメージを起動する。第11の発明に係る電子カメラは、撮影光学系からの被写体光を撮像して画像を生成する撮像素子と、請求項1から請求項10の何れか1項記載の電子機器とを備える。第12の発明は、第11の発明において、主制御部は、他のOSの起動中に静止画撮影又は動画撮影の指示入力を検出した場合、他のOSの起動を中断する。主制御部は、静止画撮影又は動画撮影の実行後に、他のOSの起動を再開する。第13の発明は、第11又は第12の発明において、第1のOSは、撮影光学系が有するレンズ情報を解析する。他の制御部は、レンズ情報の解析結果に基づいて、汎用OSとタスクの実行時間を管理するリアルタイムOSとの何れか一方を起動する。本発明によれば、起動時間の異なる複数のOSに関し、複数のOSの起動時間の効率化を図る手段を提供できる。以下、図面に基づいて本発明の実施の形態を詳細に説明する。図1は、本実施形態の電子カメラ100の構成例を説明するブロック図である。本実施形態の電子カメラ100は最初に起動したOSが起動条件を検出し、その後に起動するOSを決定するマルチコアシステムを有する。このマルチコアシステムの一例は、後述するフローの処理により実現される。電子カメラ100は、図1に示す通り、撮影光学系10と、レンズ制御部11、撮像素子12と、信号処理部13と、カードインターフェース部以下カードI/F部という14と、USBUniversalSerialBusインターフェース部以下USBI/F部という15と、フラッシュメモリ16と、SDRAMSynchronousDynamicRandomAccessMemory17と、表示モニタ18と、操作部19と、レリーズ釦20と、電源21と、通信インターフェース部以下通信I/F部という22と、ASICApplicationSpecificIntegratedCircuit23と、データバス24とを備える。このうち、信号処理部13、カードI/F部14、USBI/F部15、フラッシュメモリ16、SDRAM17、表示モニタ18、通信I/F部22及びASIC23は、データバス24を介して互いに接続されている。また、レンズ制御部11、撮像素子12、信号処理部13、操作部19、レリーズ釦20及び電源21は、ASIC23に接続されている。撮影光学系10は、ズームレンズとフォーカスレンズとを含む複数のレンズ群で構成されている。なお、簡単のため、図1では、撮影光学系10を1枚のレンズとして図示する。レンズ制御部11は、撮影光学系10内でズームレンズやフォーカスレンズのレンズ位置をASIC23の指示に応じて光軸方向に調整する。撮像素子12は、被写体の像を撮像し、アナログの画像信号を出力する。そして、撮像素子12が出力するアナログの画像信号は、信号処理部13に入力される。なお、撮像素子12の撮像面には、R赤、G緑B青の3種類のカラーフィルタが例えばベイヤー配列で配置されている。また、撮像素子12の電荷蓄積時間及び画像信号の読み出しは、タイミングジェネレータ不図示によって制御される。ここで、撮像素子12は、電子カメラ100の撮影モードにおいて、レリーズ釦20の全押し操作に応答して記録用の静止画像本画像を撮像する。また、撮像素子12は、撮影待機時にも所定間隔毎に観測用の画像スルー画像を連続的に撮像する。なお、撮像素子12は、CCDChargeCoupledDevice型又はCMOSComplementaryMetalOxideSemiconductor型のイメージセンサである。信号処理部13は、撮像素子12が出力する画像信号に対してアナログ信号処理を施すアナログフロントエンド回路AFEと、そのAFEでアナログ信号処理が施された画像信号に対して、デジタル信号処理を施すデジタルフロントエンド回路DFEとを有する。ここで、信号処理部13のAFEは、アナログの画像信号に対して相関二重サンプリングやゲイン調整をした後、アナログの画像信号をデジタルの画像信号に変換するA/D変換処理等を行なう。また、信号処理部13のDFEは、A/D変換されたデジタルの画像信号におけるノイズ成分の除去等を行なう。この信号処理部13が出力する画像信号は、RGB信号の画像データとしてSDRAM17に一時的に記録される。カードI/F部14には、着脱自在の記録媒体30を接続するためのコネクタ不図示が形成されている。そして、カードI/F部14は、そのコネクタに接続された記録媒体30にアクセスして画像の記録処理等を行なう。この記録媒体30は、例えば、不揮発性のメモリカードである。図1では、コネクタに接続された後の記録媒体30を示している。USBI/F部15には、カードI/F部14と同様、着脱自在の記録媒体31を接続するためのコネクタ不図示が形成されている。そして、USBI/F部15は、そのコネクタに接続された記録媒体31にアクセスして画像の記録処理等を行なう。この記録媒体31は、例えば、不揮発性のUSBメモリである。図1では、コネクタに接続された後の記録媒体31を示している。フラッシュメモリ16は、不揮発性メモリであって、複数のOSや複数のスナップショットイメージが格納される。図1では、簡単のため、フラッシュメモリ16は、第1のリアルタイムOS以下第1のRTOSという16a、第2のリアルタイムOS以下第2のRTOSという16b、第1の汎用OS16c、第2の汎用OS16dを格納している。ここで、第1のRTOS16aは、例えば、タスクの実行時間を管理するリアルタイムOSである。第2のRTOS16bは、第1のRTOS16aよりも起動時間の遅いRTOSである。第1の汎用OS16cは、例えばLinux登録商標等の汎用OSである。第2の汎用OS16dは、例えばLinuxとは異なる汎用OSである。また、フラッシュメモリ16は、例えば第1の汎用OS16cの起動時間を短縮する第1のスナップショットイメージ以下第1のSPという16eや第2のスナップショットイメージ以下第2のSPという16fを格納している。ここで、第1のSP16e及び第2のSP16fは、OSの一形態である。なお、Linux等の汎用OSの場合、ハードウエアを直接管理する処理を行なう中心的な機能を有するソフトウェアをカーネルと称し、カーネル以外の部分例えば、ファイルシステムやファイル操作コマンド、シェルなどの基本的なソフトウェア群をユーザランドと称している。本実施形態では、例えば、第1のSP16e及び第2のSP16fは、ユーザランドのスナップショットイメージとする。汎用OSのユーザランドをロードする場合、ユーザランドのファイルのサイズに応じて、起動時間がかかる。そこで、本実施形態では、予めユーザランドのスナップショットイメージを作成しておくことにより、起動時間を高速化することができる。また、本実施形態で使用するOSは、工場出荷時に予めインストールされていることとする。ただし、電子カメラ100では、記録媒体30、記録媒体31、又は通信I/F部22を介して、汎用OSのソフトウェアバージョンアップも含むをインストールするようにしても良い。SDRAM17は、画像データやOS等のプログラムを一時的に記録する揮発性のバッファメモリである。ここで、ASIC23は、フラッシュメモリ16に格納されている第1のRTOS16a、第2のRTOS16b、第1の汎用OS16c、第2の汎用OS16d、第1のSP16e及び第2のSP16fを必要に応じて読み出し、SDRAM17にロードして起動する。これにより、各OSは、SDRAM17に一時的に記録される。なお、図1に示すSDRAM17では、一例として、工場出荷時の状態を例示しているため、ロード前の状態として点線枠で示している。表示モニタ18は、例えば液晶表示媒体により構成される。そして、表示モニタ18は、記録用の画像、スルー画像、電子カメラ100の操作メニュー等を表示する。操作部19は、電子カメラ100を操作するための指示入力を受け付ける複数の釦不図示を有している。レリーズ釦20は、半押し操作撮影前におけるオートフォーカスAFや自動露出AE等の動作開始の指示入力と全押し操作記録用画像を取得するための撮像動作開始との指示入力とを受け付ける。電源21は、電子カメラ100の各機能ブロック等に電力を供給する。電力の供給開始及び供給停止は、ASIC23から指示により行なう。ASIC23は、各種演算及び電子カメラ100の制御を行なう。また、ASIC23は、画像データに各種の画像処理例えば、輪郭強調処理、色補間処理等を施す。さらに、ASIC23は、複数のCPUCentralProcessingUnitコアを搭載してCPUの高速化を実現するマルチコアシステムを採用している。マルチコアシステムでは、CPUをN個Nは自然数搭載するが、本実施形態では、説明の便宜上、一例として3つのCPUコアを搭載する。また、本実施形態では、最初に起動した第1のOS第1のRTOS16aが、システム状態例えば起動条件を示す動作モードを検出して、それ以降に起動するOSを決定する。具体的には、本実施形態では、複数のCPUのうちで主となる第1CPU1主制御部を設定する。これにより、第1CPU1マスター側と第2CPU2、第3CPU3とは、主従関係を形成する。例えば、第1CPU1は、第2CPU2、及び第3CPU3が起動するOSを選択する。また、第1CPU1は、複数のOSのうちで起動時間の速い第1のOS第1のRTOS16aを起動して、システム状態を示す動作モードを第1のOSに検出させる。この場合、第1のOSは、電子カメラ100の制御系の機能を管理するRTOSであって、最初に予め定められた時間内で処理可能なOSである。また、第1のOSは、複数のOSのうちで最速のOSである。そして、第1CPU1は、第1のOSによる検出結果に基づいて、第1CPU1とは異なる他のCPUで起動するOSとして、第1のOSよりも起動時間の遅い他のOSを選択する。本実施形態の他のOSは、第2のRTOS16b、第1の汎用OS16c、第2の汎用OS16d、第1のSP16e、第2のSP16fが該当する。なお、第1CPU1は、1つのCPUで起動するOSとして複数のOSを選択しても良い。図2、図3は、各動作モードにおけるシステム構成例の概念図である。図2及び図3に示す概念図では、フラッシュメモリ16に格納されているOSと、ASIC23内の第1CPU1~第3CPU3との対応関係を動作モード毎に示している。なお、図2、図3では、第1の汎用OSをLinuxとして例示している。図2aは、動作モード0のシステム構成例を示す概念図である。動作モード0は、第1のRTOS16aを起動する動作モードである。第1CPU1は、複数のOSのうちで起動時間の速い第1のRTOS16a第1のOSを起動して、システム状態を示す動作モードをその第1のRTOS16aに検出させる。動作モードの検出結果が、動作モード0の場合、第1CPU1は、フラッシュメモリ16に格納されている第1のRTOS16aを図1に示すSDRAM17にロードして起動する。図2aでは、第1SDRAM17にロードされた第1のRTOS16aを第1CPU1が使用することを概念的に表している。つまり、動作モード0では、最初に起動時間が最速の第1のRTOS16aを起動することで、起動時間の効率化を図る。図2bは、動作モード1のシステム構成例を示す概念図である。動作モード1は、第1のRTOS16aと、第1の汎用OS16cLinuxを起動する動作モードである。ここで、動作モードの検出結果が動作モード1の場合、第1CPU1は、第2CPU2で起動する第1の汎用OS16cを選択する。これにより、第1CPU1は、第1のRTOS16aを起動し、第2CPU2は、その第1のRTOS16aよりも起動時間の遅い第1の汎用OS16cを起動する。具体的には、第1CPU1は、図2aに示す動作モード0と同様、第1のRTOS16aを起動する。また、第2CPU2は、フラッシュメモリ16に格納されている第1の汎用OS16cをSDRAM17にロードして起動する。図2bでは、第1SDRAM17にロードされた第1のRTOS16aを第1CPU1が使用し、SDRAM17にロードされた第1の汎用OS16cLinuxを第2CPU2が使用することを概念的に表している。なお、動作モード1の場合、第2CPU2は、第1のRTOS16aよりも起動時間の遅い他の汎用OSを起動しても良い。つまり、動作モード1では、起動時間が最速の第1のRTOS16aを起動し、続いて、高機能な汎用OSを起動することにより、起動時間の効率化を図ることができる。また、動作モード1では、第1の汎用OSの起動中に第1のRTOS16a側で発生した優先タスクの起動に応じて、第1の汎用OSの起動を中断又は中止することができる詳細は後述する。また、動作モード1では、電子カメラ100の撮影光学系10の制御や、撮像素子12の撮像制御、信号処理部13内での画像信号の処理については、第1のRTOS16aで実行する。一方、ASIC23は、例えば、信号処理部13が出力した画像データの画像処理については、第1の汎用OSで実行する。すなわち、動作モード1では、ASIC23の処理に応じて、OSを使い分けることができる。図2cは、動作モード1のシステム構成例変形例を示す概念図である。動作モードの検出結果が動作モード1の場合、第1CPU1は、第1のRTOS16aを起動し、第2CPU2は、例えば第1のSP16eと第1の汎用OS16cのカーネル部分とを起動しても良い。具体的には、第1CPU1は、第1のRTOS16aをSDRAM17にロードして起動する。また、第2CPU2は、フラッシュメモリ16に格納されている第1のSP16eユーザランド部分と第1の汎用OS16cのカーネル部分とをSDRAM17にロードして起動する。図2cでは、第1SDRAM17にロードされた第1のRTOS16aを第1CPU1が使用し、SDRAM17にロードされた第1の汎用OS16cカーネル部及び第1のSP16eユーザランド部分からなるLinuxを第2CPU2が使用することを概念的に表している。なお、第2CPU2は、必要に応じてフラッシュメモリ16に格納されている第1のSP16e或いは第2のSP16fをSDRAM17にロードして起動しても良いし、又は、第2CPU2は、必要に応じて第1のSP16e、第2のSP16fをSDRAM17にロードして起動しても良い。つまり、動作モード1の変形例では、汎用OSの起動の高速化を実現できる。図3aは、動作モード2のシステム構成例を示す概念図である。動作モード2は、第1のRTOS16a及び第2のRTOS16bを起動する動作モードである。ここで、動作モードの検出結果が動作モード2の場合、第1CPU1は、第2CPU2で起動する第2のRTOS16bを選択する。これにより、第1CPU1は、第1のRTOS16aを起動し、第2CPU2は、その第1のRTOS16aよりも起動時間の遅い第2のRTOS16bを起動する。そのため、動作モード2では、動作モード1と同様、起動時間が最速の第1のRTOS16aを起動し、続いて、第2のRTOS16bを起動することにより、起動時間の効率化を図ることができる。具体的には、第1CPU1は、第1のRTOS16aをSDRAM17にロードして起動する。また、第2CPU2は、フラッシュメモリ16に格納されている第2のRTOS16bをSDRAM17にロードして起動する。図3aでは、第1SDRAM17にロードされた第1のRTOS16aを第1CPU1が使用し、SDRAM17にロードされた第2のRTOS16bを第2CPU2が使用することを概念的に表している。なお、第2のRTOS16bは、例えば、高精度なレンズ駆動やAF演算等の処理を行なう。つまり、動作モード2では、動作モード1と同様、ASIC23の処理に応じて、OSを使い分けることができる。図3bは、動作モード3のシステム構成例を示す概念図である。動作モード3は、第1のRTOS16a、第2のRTOS16、第1の汎用OS16cを起動する動作モードである。動作モードの検出結果が動作モード3の場合、第1CPU1は、第1のRTOS16aを起動し、第2CPU2は、第2のRTOS16bを起動し、第3CPU3は、第1の汎用OS16cを起動する。具体的には、第1CPU1は、第1のRTOS16aをSDRAM17にロードして起動する。また、第2CPU2は、第2のRTOS16bをSDRAM17にロードして起動する。さらに、第3CPU3は、第1の汎用OS16cをSDRAM17にロードして起動する。図3bでは、第1SDRAM17にロードされた第1のRTOS16aを第1CPU1が使用し、SDRAM17にロードされた第2のRTOS16bを第2CPU2が使用し、SDRAM17にロードされた第1の汎用OS16cLinuxを第3CPU3が使用することを概念的に表している。つまり、動作モード3では、動画撮影等の処理の機能を第1の汎用OS16cを用いて実行するのに適している。また、一例として、高精度なレンズ駆動やAF演算等の処理、撮影された記録用の画像を無線LAN通信で外部に送信する送信処理を行なう場合には、第3のモードを選択することが好ましい。すなわち、動作モード3では、高精度なレンズ駆動やAF演算等の処理を行なうため、第2のRTOS16bを起動し、送信処理を行なうため、第1の汎用OS16cLinuxを起動しても良い。また、動作モード3では、第1のRTOS16aは、撮影光学系10が有するレンズ情報を解析しても良い。第2CPU2は、レンズ情報の解析結果に基づいて、第2のRTOS16bと第1の汎用OS16cLinuxとの何れか一方を起動しても良い。従って、動作モード3では、各々の処理に適したOSを効率良く使い分けて起動できる。図3cは、動作モード4のシステム構成例を示す概念図である。動作モード4は、第1の汎用OS16cを複数の制御部第2CPU2及び第3CPU3で共有して管理使用する動作モードである。ここで、動作モードの検出結果が動作モード4の場合、第1CPU1は、複数の制御部第2CPU2及び第3CPU3で起動する第1の汎用OS16cを選択する。これにより、第1CPU1は、第1のRTOS16aを起動し、第2CPU2及び第3CPU3は、第1の汎用OS16cを起動する。ここで、動作モード4は、例えば、個々のCPUが対等の条件でメモリを共有する並列処理方式の対称型マルチプロセッシングSMP:SymmetricMultiprocessingである。図3cでは、第1SDRAM17にロードされた第1のRTOS16aを第1CPU1が使用し、SDRAM17にロードされた第2のRTOS16bを第2CPU2及び第3CPU3が対称型マルチプロセッシングにより使用することを概念的に表している。なお、第1CPU1は、第2CPU2及び第3CPU3で起動する汎用OSとして、例えば、第1のSP16e、第2のSP16fの何れかを選択しても良い。具体的には、第1CPU1は、第1のRTOS16aをSDRAM17にロードして起動する。また、第2CPU2及び第3CPU3は、第1の汎用OS16cをSDRAM17にロードして起動する。そのため、動作モード4では、動作モード1と同様、最初に起動時間が最速の第1のRTOS16aを起動し、続いて、第1の汎用OS16cを起動することにより、起動時間の効率化を図ることができる。つまり、動作モード4は、例えば、第1の汎用OS16cの並列処理に優れている。次に、本実施形態の電子カメラ100におけるOSの起動処理の一例を説明する。図4は、電子カメラ100の電源オン時における動作の一例を示すフローチャートである。ここで、操作部19が電子カメラ100の電源オンの指示入力を受け付けた場合、ASIC23の第1CPU1は、図4に示すフローの処理を開始させる。図4では、動作モード1の場合について例示する。そのため、先ず第1CPU1側のフローの処理を説明した後、第2CPU2側のフローの処理を説明する。なお、動作モード2~4の場合についても、基本的に動作モード1の場合のフロー処理と同様である。ステップS101:第1CPU1は、CPU識別番号CPUIDの確認をし、RTOS1の起動処理を開始する。具体的には、マルチコアシステムを採用しているため、各々のCPUがどの識別番号に属するCPUであるのかを確認する。第1CPU1は、フラッシュメモリ16に記録されているCPU識別番号を参照し、マスター側のCPUであることを確認する。これにより、第1CPU1は、第1のRTOS16aの起動処理を開始する。すなわち、第1CPU1は、フラッシュメモリ16に格納されている第1のRTOS16aをSDRAM17にロードして起動する。ステップS102:第1CPU1は、第1のRTOS16aの起動終了後に、動作モードを検出する。具体的には、第1CPU1は、一例として、ユーザが前回電源をオフした際の、電子カメラ100の動作モードをフラッシュメモリ16に記録しておく。第1CPU1は、第1のRTOS16aの起動終了後に、フラッシュメモリ16に記録されている動作モードを参照することにより検出する。ステップS103:第1CPU1は、動作モードに基づいて、OSを選択し、起動するCPUに起動許可通知を送信する。例えば、第1CPU1は、動作モード1を検出する。これにより、第1CPU1は、第2CPU2で起動する第1の汎用OS16cを選択する。そして、第1CPU1は、第2CPU2に起動許可通知を送信する。ステップS104:第1CPU1は、優先処理タスクの発生の有無を確認する。優先処理タスクは、第1CPU1以外の第2CPU2又は第3CPU3の起動のタスクよりも優先度の高いタスクである。優先処理タスクは、例えば、静止画撮影又は動画撮影の指示入力、動作モードの変更、電源システムの異常状態の検出等がある。ステップS105:第1CPU1は、優先処理タスクの有無を判定する。優先処理タスクのイベントが発生した場合ステップS105:Yes、第1CPU1は、ステップS106の処理に移行する。優先処理タスクのイベントが発生していない場合ステップS105:No、第1CPU1は、ステップS104の処理を繰り返す。ステップS106:第1CPU1は、第2CPU2に対して起動処理の中断又は中止通知を送信する。具体的には、第1CPU1は、静止画撮影又は動画撮影の指示入力、電源システムの異常状態の検出の場合、起動処理の中断通知を送信する。一方、第1CPU1は、動作モードの変更の場合、起動処理の中止強制終了通知を送信する。ステップS107:第1CPU1は、優先処理タスクの実行を行なう。そして、第1CPU1は、優先処理タスクの終了後に第2CPU2に対して再開通知の送信を行なう。ステップS108:第1CPU1は、第2CPU2からの起動完了通知の受信待ちの処理を行なう。具体的には、起動完了通知を受信しない場合ステップS108:No、第1CPU1は、ステップS108の処理を繰り返す。一方、起動完了通知を受信した場合ステップS108:Yes、第1CPU1は、図4に示す第1CPU1側のフローの処理を終了させる。次に、第2CPU2側のフローの処理を説明する。ステップS201:第2CPU2は、CPU識別番号CPUIDを確認する。第2CPU2は、フラッシュメモリ16に記録されているCPU識別番号を参照し、第1CPU1の従属側のCPUであることを確認する。ステップS202:第2CPU2は、起動許可通知の待ち状態に遷移する。ステップS203:第2CPU2は、第1CPU1からの起動許可通知の受信待ちの処理を行なう。具体的には、起動許可通知を受信しない場合ステップS203:No、第1CPU1は、ステップS203の処理を繰り返す。一方、起動許可通知を受信した場合ステップS203:Yes、第2CPU2は、ステップS204の処理に移行する。ステップS204:第2CPU2は、汎用OSの起動処理のサブルーチンを実行する詳細は後述する。ステップS205:第2CPU2は、OS起動完了通知の送信を行なう。そして、第2CPU2は、図4に示す第2CPU2側のフローの処理を終了させる。次に、汎用OSの起動処理について説明する。図5は、汎用OSの起動処理のサブルーチンを示すフローチャートである。ステップS301:第2CPU2は、第1の汎用OS16cの起動処理を開始する。具体的には、第2CPU2は、フラッシュメモリ16に格納されている第1の汎用OS16cをSDRAM17にロードする処理を開始する。図6は、第1の汎用OS16cの起動処理を説明する概念図である。第1CPU1は、既に第1のRTOS16aを起動している。そこで、第1CPU1は、第1のRTOS16a上で動作する第1のアプリケーションプログラム第1のApplを起動して、フラッシュメモリ16に格納されている第1の汎用OS16cLinuxのカーネル部分をSDRAM17にロードする処理を開始する。続いて、第1CPU1は、第1のアプリケーションプログラムを用いて、例えば第1のSP16eと第2のSP16fとの何れか一方のユーザランドをSDRAM17にロードする処理を開始する。これにより、第2CPU2は、Linux上で動作する第2のアプリケーションプログラム第2のApplを起動する。ステップS302:第2CPU2は、起動完了を監視する。そして、起動完了した場合ステップS302:Yes、第2CPU2は、図5に示すサブルーチンのフローの処理を終了して、図4に示すステップS205の処理に移行する。一方、起動完了していない場合ステップS302:No、第2CPU2は、ステップS303の処理に移行する。ステップS303:第2CPU2は、第1CPU1側から中止通知を受信したか否かの有無を判定する。中止通知を受信した場合ステップS303:Yes、第2CPU2は、ステップS309の処理に移行する。そして、第2CPU2は、第1の汎用OS16cの起動処理を強制終了する。そして、第2CPU2は、図4に示す第2CPU2側のフローの処理を終了させるステップS309。この場合、第1CPU1は、中止通知を第2CPU2に送信しているので、図4に示すステップS107の再開通知送信の処理と、ステップS108の完了通知の受信の処理とをスキップする。一方、中止通知を受信していない場合ステップS303:No、第2CPU2は、ステップS304の処理に移行する。ステップS304:第2CPU2は、第1CPU1側から中断通知を受信したか否かの有無を判定する。中断通知を受信していない場合ステップS304:No、第2CPU2は、ステップS302の処理に戻る。一方、中断通知を受信した場合ステップS304:Yes、第2CPU2は、ステップS305の処理に移行する。ステップS305:第2CPU2は、第1の汎用OS16cの起動処理を中断して、再開待ち状態に遷移する。そして、第2CPU2は、ステップS306の処理に移行する。ステップS306:第2CPU2は、第1CPU1側から再開通知を受信したか否かの有無を判定する。再開通知を受信していない場合ステップS306:No、第2CPU2は、ステップS306の処理を繰り返す。一方、再開通知を受信した場合ステップS306:Yes、第2CPU2は、ステップS307の処理に移行する。ステップS307:第2CPU2は、第1の汎用OS16cの起動処理を再開する。そして、第2CPU2は、ステップS308の処理に移行する。ステップS308:第2CPU2は、起動処理の終了を監視する。起動処理が完了していない場合ステップS308:No、第2CPU2は、ステップS308の処理を繰り返す。一方、起動処理が完了した場合ステップS308:Yes、第2CPU2は、図5に示すサブルーチンのフローの処理を終了して、図4に示すステップS205の処理に移行する。以上、本実施形態の電子カメラ100は、複数のOSの起動時間を効率化するための複数の動作モードを備える。また、電子カメラ100は、汎用OSのスナップショットイメージを作成して起動することにより、起動時間の高速化を行なうこともできる。さらに、電子カメラ100は、汎用OSの起動中に上述した優先処理タスクのイベントが発生した場合、汎用OSの起動を中断すると共に、その優先処理タスクの終了後に、汎用OSの起動を再開することができる。これにより、本発明は、起動時間の異なる複数のOSに関し、複数のOSの起動時間の効率化を図る手段を提供できる。実施形態の補足事項1上記の実施形態では、汎用OSとして、Linuxを用いて説明したが、汎用OSは、Linuxに限られず、例えば、Windows登録商標、UNIX登録商標、JAVA登録商標等の他の汎用OSであっても良い。2上記の実施形態では、本発明の電子機器を搭載して電子カメラを例示したが、本発明の電子機器は、RTOSと汎用OSとを使用する電子機器であれば良く、例えば携帯電話であっても良い。3上記の実施形態では、フラッシュメモリ18は、内部の基本回路の構成によってNOR否定論理和型とNAND否定論理積型との何れかであって良い。なお、NOR否定論理和型のフラッシュメモリの場合、第1CPU1、第2CPU2、第3CPU3は、SDRAM17にロードせずに、RTOSや汎用OSを起動することができる。これにより、電子カメラ100は、起動時間を高速化することができる。