JP2023064689A

JP2023064689A - コンピュータシステムの基板管理コントローラ及び起動方法

Info

Publication number: JP2023064689A
Application number: JP2022103553A
Authority: JP
Inventors: 江王; Jiang Wang
Original assignee: Xunmu Information Technology Shanghai Co Ltd
Current assignee: Xunmu Information Technology Shanghai Co Ltd
Priority date: 2021-10-26
Filing date: 2022-06-28
Publication date: 2023-05-11
Also published as: CN113934471A; TW202223636A; US20230129037A1

Abstract

【課題】より安定した動作環境を有する改良された基板管理コントローラ及びその起動方法を提供する。
【解決手段】コンピュータシステム１００において、基板管理コントローラ１２０は、フラッシュメモリ１３０及びマイクロプロセッサ１２２を含む。フラッシュメモリは、予め起動領域、第１の領域及び第２の領域に仕切られ、起動領域には起動ファームウエアが格納される。第１の領域は第１のファイルシステムにフォーマットされ、第２の領域は第２のファイルシステムにフォーマットされる。第１のファイルシステムには、第１のオペレーティングシステムイメージファイル及び第１のアプリケーションソフトウエアが格納され、且つ、第２のファイルシステムには第２のオペレーティングシステムイメージファイル及び第２のアプリケーションソフトウエアが格納される。
【選択図】図１

Description

本出願はコンピュータシステムの管理コントローラに関し、特に、サーバ又はハイエンドスイッチに適用可能なより速い起動速度とより高い信頼性を有する改良型基板管理コントローラに関する。

基板管理コントローラ(Board Management Controller;ＢＭＣ)は主にサーバ又はハイエンドスイッチ等のコンピュータシステムで使用され、システムのハードウエアの状態管理、オペレーティングシステムの管理、健康状態の管理、電力消費の管理など、中心的な機能を担う。よって、基板管理コントローラの起動速度及び信頼性は非常に重要である。基板管理コントローラの起動が遅れると、システム全体の起動時間にも影響を及ぼす。基板管理コントローラの実行が不安定になると、システム全体の安定性も影響を受ける。

図１は従来のコンピュータシステム１００及び基板管理コントローラ１２０のアーキテクチャ図である。コンピュータシステム１００には基板管理コントローラ１２０が含まれる。当該基板管理コントローラ１２０は少なくともマイクロプロセッサ１２２、メモリ１２４、及びフラッシュメモリ１３０を含む。

基板管理コントローラ１２０自体は１つの組み込み型プロセッサであり、当該マイクロプロセッサ１２２上で実行されるソフトウエアは、起動ファームウエア１３２、オペレーティングシステム１３４(一般的にはＬｉｎｕｘ(登録商標))、及びファイルシステム１３６を含む。基板管理コントローラが一般的に使用するアプリケーションソフトウエアは主にファイルシステム１３６に格納される。

図１に示されるように、上記起動ファームウエア１３２、オペレーティングシステム１３４及びファイルシステム１３６はフラッシュメモリ１３０内に位置する。フラッシュメモリ１３０の開始領域は起動ファームウエア１３２を格納する。起動ファームウエア１３２の一般的なシステムはＵ－Ｂｏｏｔであり、容量は約０.５MBを占有する。次に前記起動ファームウエア１３２の後のスペースには、オペレーティングシステム１３４のイメージファイルが格納される。オペレーティングシステム１３４のイメージファイルは通常、Ｌｉｎｕｘコアイメージが使用され、そのサイズは通常、数メガバイト(Megabytes;MB)以内、例えば２～５MBである。

フラッシュメモリ１３０の残りの部分は被ファイルシステム(File System)にフォーマットされ、基板管理コントローラのアプリケーションソフトウエアを格納するために用いられる。現在、最も多く使用されているファイルシステムはフラッシュメモリジャーナル型ファイルシステム(Journaling Flash File System;ＪＦＦＳ)である。

図２は従来の基板管理コントローラ１２０の起動フローチャートである。ステップ２０１では、前記基板管理コントローラ１２０を起動する。ステップ２０３では、フラッシュメモリ１３０から起動ファームウエア１３２を読み出して実行する。基板管理コントローラ１２０を起動又は再起動した後、基板管理コントローラ１２０内のマイクロプロセッサ１２２はまずフラッシュメモリ１３０から起動ファームウエア１３２を読み出す。

ステップ２０５では、起動ファームウエア１３２が実行された後、マイクロプロセッサ１２２は配置されたガイドアドレスに基づいてフラッシュメモリ１３０内のオペレーティングシステム１３４をロードし、オペレーティングシステム１３４の実行を開始させる。ステップ２０７では、オペレーティングシステム１３４が実行された後、中に含まれるファイルシステム駆動プログラムをロードして、マイクロプロセッサ１２２にフラッシュメモリ１３０内の予めフォーマットされたファイルシステム１３６を論理ハードディスクとしてマウント(mount)する能力を持たせる。続いてステップ２０９では、基板管理コントローラはマウントが成功したファイルシステム１３６からアプリケーションソフトウエアを読み出して実行する。

従来のフラッシュメモリのレイアウト及び起動手順には以下の問題がある。

従来のフラッシュメモリのレイアウト及び起動手順の柔軟性は低い。オペレーティングシステム１３４を格納する領域はアドレス及び長さが固定されており、予め確保しておくスペースが大きすぎると、スペースの無駄使いになる一方、予め確保しておくスペースが小さすぎると、将来、オペレーティングシステム１３４の更新時に、もし新しいバージョンのオペレーティングシステム１３４が確保しておいたスペースより大きい場合、フラッシュメモリ１３０全体のレイアウトを変更する必要があり、プロセスが複雑で時間もかかる。

従来のフラッシュメモリのレイアウト及び起動手順の信頼性は低い。オペレーティングシステム１３４とファイルシステム１３６にはバックアップ機構がなく、一旦、更新に問題が生じ、ファイルシステム１３６に予想外の破損が生じると、基板管理コントローラ１２０は起動できなくなり、コンピュータシステム１００は正常機能を失う。

従来のフラッシュメモリのレイアウト及び起動手順の性能は低い。ＪＦＦＳファイルシステムの性能はフラッシュメモリ容量の増大に伴って低下する可能性がある。

本願は、上記技術課題を解決するために、本出願の実施例は、下記のより安定した動作環境を有する改良された基板管理コントローラを提供する。

上記技術課題を解決するために、本出願の実施例は、下記のより安定した動作環境を有する改良された基板管理コントローラを提供する。

前記基板管理コントローラはフラッシュメモリ及びマイクロプロセッサを含む。前記フラッシュメモリは起動領域、第１の領域及び第２の領域に仕切られ、前記起動領域には起動ファームウエアが格納され、前記第１の領域は第１のファイルシステムにフォーマットされ、前記第２の領域は第２のファイルシステムにフォーマットされ、前記第１のファイルシステムには第１のオペレーティングシステムイメージファイル及び第１のアプリケーションソフトウエアが格納され、且つ前記第２のファイルシステムには第２のオペレーティングシステムイメージファイル及び第２のアプリケーションソフトウエアが格納される。

前記基板管理コントローラの起動時に、前記マイクロプロセッサが前記起動領域から前記起動ファームウエアをロードして実行する。前記マイクロプロセッサは予め決定された構成プロファイルに基づき、前記第１のファイルシステム又は前記第２のファイルシステムを選択的にマウントする。マウント成功後、続いてマウントされたファイルシステムから対応のオペレーティングシステムイメージファイル及びアプリケーションソフトウエアをロードして実行することで、前記コンピュータシステムに対する制御を実現する。

さらなる実施例において、前記第１のオペレーティングシステムイメージファイルは工場出荷時バージョンオペレーティングシステムを含み、前記第２のオペレーティングシステムイメージファイルは運営バージョンオペレーティングシステムを含むことができる。このような場合、工場出荷時バージョンは通常、基本機能のみを含み、運営バージョンは複数の付加機能を含むことができるため、前記第２のファイルシステムの構成容量は前記第１のファイルシステムの容量より大きくすることができる。

この他、工場出荷時バージョンは通常、バックアップシステムとされ、完全性をできるだけ維持しなければならないため、前記第１のファイルシステムがマウントされる時、リードオンリーモードでマウントされる。運営バージョンは頻繁な更新が許可されるため、前記第２のファイルシステムがマウントされる時、リード・ライトモードでマウントされる。

さらなる実施例において、第１の領域及び第２の領域は完全に同じで、お互いのバックアップとされてもよい。このような場合、前記第１のオペレーティングシステムイメージファイルと前記第２のオペレーティングシステムイメージファイルは同じバージョンであり、且つ前記第２のファイルシステムの容量と前記第１のファイルシステムの容量は同じである。両者ともリード・ライトモードでマウントされることができる。

さらなる実施例において、前記第１のファイルシステム又は前記第２のファイルシステムはフラッシュメモリジャーナル型ファイルシステム(Journaling Flash File System、ＪＦＦＳ)である。一方、前記第１のファイルシステム又は前記第２のファイルシステムは未ソートブロックイメージファイルシステム(Unsorted Block Image File System、ＵＢＩＦＳ)でもよい。

さらなる実施例において、前記マイクロプロセッサは前記第１のファイルシステム又は前記第２のファイルシステムをマウントする時、マウントされたファイルシステムが破損していることを発見した場合、他方のファイルシステムをマウントするように変えてもよい。他方のファイルシステムをマウントするように変えて起動が成功した後、さらに、破損したファイルシステムに修復プログラムを実行することができる。

本出願はまた、上記改良された基板管理コントローラを備え、前記基板管理コントローラにより制御され、起動、シャットダウン、リセット、システムファームウエアアップグレード、及び実行データ監視のうち少なくとも１つの機能を実行する、コンピュータシステムの実施例を提供する。

本出願はさらに、前記基板管理コントローラのアーキテクチャに基づく基板管理コントローラの起動方法の実施例を提供する。まず前記基板管理コントローラの起動時に、前記起動領域から前記起動ファームウエアをロードして実行する。次に予め決定されている構成プロファイルに基づき、第１のファイルシステム又は第２のファイルシステムを選択的にマウントする。最後にマウントされたファイルシステムから対応のオペレーティングシステムイメージファイル及びアプリケーションソフトウエアをロードして実行することで、コンピュータシステムを制御する機能を実現する。

従来の一般的な基板管理コントローラのフラッシュメモリレイアウト及び起動手順に比べ、本発明は明らかな優位性を持つ。

本出願の基板管理コントローラのフラッシュメモリレイアウトの柔軟性は高い。従来のフラッシュメモリ１３０では、アドレスオフセット及びサイズの両方が予め決められていた。本実施例では、オペレーティングシステムのイメージファイルを、固定の仕切られたパーティション内ではなく、フラッシュメモリ４００のファイルシステムに格納する。こうすることで、フラッシュメモリのスペースを節約できるだけでなく、様々なサイズのファイルを収容することができる。

本出願の基板管理コントローラのフラッシュメモリレイアウトの信頼性は高い。フラッシュメモリはファイルシステムを格納するために２つのパーティションに仕切られる。１つのパーティションでファイルの更新などの原因により予想外に破損した場合、他方のパーティションから起動して業務を運営する又は破損したパーティションを修復することができる。

本出願の基板管理コントローラのフラッシュメモリレイアウトの性能は向上する。ＵＢＩＦＳはフラッシュメモリのサイズに対して優れた拡張性を有し、ロード時間、メモリの消費及びアクセス速度はフラッシュメモリサイズに依存せず、性能は明らかにＪＦＦＳよりも優れる。ＵＢＩＦＳフラッシュメモリファイルシステムを使用すれば、基板管理コントローラの起動速度を加速させることができる。

フラッシュメモリにおいてファイルシステムを格納するための２つのパーティションは同じサイズであってもよく、格納するコンテンツやリード・ライト属性も実際の状況に合わせて調整することができる。例えば２つのパーティションの両方に業務運営バージョンを格納し、両方ともリード・ライト可能とし、お互いのバックアップとされてもよい。

図１は従来のコンピュータシステム１００及び基板管理コントローラ１２０のアーキテクチャ図である。図２は従来の基板管理コントローラ１２０の起動フローチャートである。図３は本出願の実施例のコンピュータシステム３００及び基板管理コントローラ３１０のアーキテクチャ図である。図４は本出願の実施例の基板管理コントローラ３１０内のフラッシュメモリ４００のアーキテクチャ図である。図５は本出願の実施例の基板管理コントローラ３１０の起動フローチャートである。

以下に本出願の実施例における図面と合わせて、本出願の実施例における技術方案を明瞭に、完全に説明する。説明される実施例は本出願の一部の実施例であり、全ての実施例ではないことは明らかである。本出願の実施例に基づき、当業者は創造的な労働を行わないで得られた他の実施例は全て本出願の保護範囲に属すものである。

図３は本出願の実施例のコンピュータシステム３００及び基板管理コントローラ３１０のアーキテクチャ図である。コンピュータシステム３００は主に一メインボード(又は基板と称す)からなり、少なくともシステムフラッシュメモリ３０２、システムメモリ３０６及びシステムプロセッサ３０８を含む。

システムフラッシュメモリ３０２にはシステムファームウエア３０４が格納され、コンピュータシステム３００を起動できるよう、システムプロセッサ３０８によりロードされる。システムメモリ３０６はコンピュータシステム３００の動作に必要なデータを格納するためのものであり、実施の詳細はここでは説明しない。コンピュータシステム３００はさらに本出願で提供する改良型基板管理コントローラ３１０を備える。当該基板管理コントローラ３１０はコンピュータシステム３００を制御して、起動、シャットダウン、リセット、システムファームウエアアップグレード、及び実行データ監視のうち少なくとも１つの機能を実行できる。

基板管理コントローラ３１０はコンピュータシステム３００中のカーネル制御ユニットであり、コンピュータシステム３００中の異なる機能のモジュール及びアセンブリを管理及び連結するために使用できる。例を挙げると、基板管理コントローラ３１０はＰＣＩ－ｅ及びＬＰＣバスを介してシステムプロセッサ３０８に接続でき、ＤＤＲバスを介してシステムメモリ３０６に接続できるとともに、ＳＰＩバスを介してシステムフラッシュメモリ３０２に接続できる。このように、コンピュータシステム３００上の各アセンブリは基板管理コントローラの管理によって円滑に動作することができる。

この他、基板管理コントローラ３１０はコンピュータシステム３００の各アセンブリと連結ハードウエアの動作データを収集することにより、異常状態が検出された場合、警告メッセージがメンテナンススタッフに自動発信され、メンテナンススタッフはコンピュータシステム３００から提供される情報に基づいてリモート診断及びトラブルシューティングを行うことができる。

基板管理コントローラ３１０には少なくともマイクロプロセッサ３２０及びフラッシュメモリ４００が含まれ、さらに、メモリ３１２、表示モジュール３１４、ネットワークモジュール３１６、及びインタフェースモジュール３１８を含んでもよい。メモリ３１２はマイクロプロセッサ３２０の動作に必要なデータを格納するためのものである。表示モジュール３１４は、現場メンテナンススタッフが当該基板管理コントローラ３１０の端末画面を読み取ることができるよう、コンピュータシステム３００から独立したディスプレイインタフェース、例えばＤ－ｓｕｂ、ＤＶＩ、ＨＤＭＩ(登録商標)などを外部に提供してもよい。

ネットワークモジュール３１６は、メンテナンススタッフが基板管理コントローラ３１０をリモート操作できるよう、コンピュータシステム３００から独立したネットワークインタフェース、例えばＲＪ－４５又はＲＧＭＩＩを提供してもよい。インタフェースモジュール３１８は、メンテナンススタッフによりキーボード・マウスを現場で連結してシステムを操作できるよう、コンピュータシステム３００から独立した序列串インタフェース、例えばUSB又はSerial Portを提供してもよい。

本実施例のフラッシュメモリ４００は、起動ファームウエア４０４、第１のファイルシステム４１０、及び第２のファイルシステム４２０を含められるよう、予め特別に仕切られている。

そして、基板管理コントローラ３１０の起動後にロードすべきオペレーティングシステムがイメージファイル形式で第１のファイルシステム４１０及び第２のファイルシステム４２０内に格納されている。

このような手法の利点として、第１のファイルシステム４１０及び第２のファイルシステム４２０において、オペレーティングシステムだけでなく、アプリケーションソフトウエアも格納できるため、スペース配置の自由度が非常に高い。フラッシュメモリ４００はオペレーティングシステムのサイズに対して特別にスペースを配置する必要がない。マイクロプロセッサ３２０はＳＰＩバスを介して前記フラッシュメモリ４００に接続できる。

基板管理コントローラ３１０の起動時に、前記マイクロプロセッサ３２０はまずフラッシュメモリ４００の先頭アドレスから前記起動ファームウエア４０４をロードして実行することができる。起動ファームウエア４０４はファイルシステムの駆動プログラム及び構成プロファイルを含むように改良することができ、これによりマイクロプロセッサ３２０は第１のファイルシステム４１０及び第２のファイルシステム４２０をマウントしてアクセスできるようになる。

構成プロファイルに基づき、前記マイクロプロセッサ３２０は前記第１のファイルシステム４１０及び前記第２のファイルシステム４２０のうちの１つを選択的にマウントし、動作時に使用する論理ハードディスクとすることができる。マウント成功後、前記マイクロプロセッサ３２０はマウントされたファイルシステムから対応のオペレーティングシステムイメージファイル及びアプリケーションソフトウエアをロードして実行することで、前記コンピュータシステムを制御する機能を実現する。

より適切な実施例において、フラッシュメモリ４００内の起動ファームウエア４０４以外の領域は、メモリテクノロジーデバイス(Memory Technology Device Partition；MTD)仕様の技術を用いて第１の領域４１２及び第２の領域４２２に仕切る(Partition)ことができ、それからフォーマットツール、例えばUBI toolsにより、それぞれ対応の第１の領域４１２及び第２の領域４２２に第１のファイルシステム４１０及び第２のファイルシステム４２０を生成する。

もう１つの可能な手法としては、フラッシュメモリ４００内の起動ファームウエア４０４以外の領域を１つのＭＴＤパーティションとして仕切り、それから当該ＭＴＤパーティションを異なるＵＢＩボリューム(Volume)に切断し、それぞれ第１のファイルシステム４１０及び第２のファイルシステム４２０のスペースとすることである。ＵＢＩボリュームを用いるメリットは２つの領域の間のサイズを柔軟に調整できることである。

別の実施例において、第１のファイルシステム４１０及び第２のファイルシステム４２０を選択するための前記構成プロファイルは、工場出荷時時に定められた値でも、又は使用過程で必要に応じて変更された値でもよい。

例を挙げると、第１のファイルシステム４１０及び第２のファイルシステム４２０のうちの１つが破損した場合、又はそのうちのオペレーティングシステムアップグレードに失敗した場合、基板管理コントローラ３１０は他方の正常なファイルシステムから起動して、基本動作能力を維持し、さらには自己修復能力を発揮することができる。

図４は本出願の実施例の基板管理コントローラ３１０内のフラッシュメモリ４００のアーキテクチャ図である。

本実施例の具体的な設計では、図１のオペレーティングシステム１３４を格納するパーティションを撤回し、フラッシュメモリ４００全体を３つのパーティション、即ち、起動領域４０２、第１の領域４１２及び第２の領域４２２に仕切る。起動領域４０２は起動ファームウエア４０４を格納する。起動領域４０２はフラッシュメモリ４００の最先端に位置し、アドレス０を含むため、基板管理コントローラ３１０の再起動後、自発的に当該起動領域４０２から起動ファームウエア４０４を読み出す。

第１の領域４１２及び第２の領域４２２はそれぞれ第１のファイルシステム４１０及び第２のファイルシステム４２０にフォーマットされ、それぞれ同じ又は異なる容量サイズで構成される。第１のファイルシステム４１０は工場出荷時バージョンの第１のオペレーティングシステムイメージファイル４１４を格納するためのものとして使用できる。工場出荷時バージョンの第１のオペレーティングシステムイメージファイル４１４は通常、基本機能のみを含むため、必要とされる容量は比較的少なく、例えば２０MBほどである。

第２のファイルシステム４２０は運営バージョンの第２のオペレーティングシステムイメージファイル４２４を格納するためのものとして使用できる。通常、運営バージョンの第２のオペレーティングシステムイメージファイル４２４は、さらに、アップグレード機能又はエラー回復のために各第２のアプリケーションソフトウエア４２６が付加されているため、割り当てられる容量は比較的多く、例えば４３.５MBとされる。第１のファイルシステム４１０及び第２のファイルシステム４２０が特定のファイルシステムでフォーマットされている場合は、そのパーティションの容量の割り当ては実際の状況に応じて柔軟に調整することも可能である。

例を挙げると、第１のファイルシステム４１０及び第２のファイルシステム４２０はＵＢＩＦＳにフォーマットされてもよい。ＵＢＩＦＳの全体性能はＪＦＦＳよりも優れ、そのアクセス速度はフラッシュメモリ容量が増大しても悪化しない。使用過程において、第１のファイルシステム４１０のコンテンツはリードオンリー属性であり、第２のファイルシステム４２０のコンテンツはリード・ライトとし、ファイルのアップグレードが許可される。

予め決定された構成により、基板管理コントローラ３１０の起動後、第２のファイルシステム４２０内の第２のオペレーティングシステムイメージファイル４２４を優先的にロードしてもよい。第２のファイルシステム４２０が破損してマウントできない場合、又は第２のオペレーティングシステムイメージファイル４２４のアップグレード後にエラーが発生して起動できない場合、起動ファームウエア４０４内の論理プログラムは、基板管理コントローラ３１０を起動させるよう、第１のファイルシステム４１０をマウントし、第１のオペレーティングシステムイメージファイル４１４をロードするようマイクロプロセッサ３２０に指示できる。第１のファイルシステム４１０には、さらに第１のアプリケーションソフトウエア４１６が含まれる。

第１のオペレーティングシステムイメージファイル４１４がロードされ起動された後、基板管理コントローラ３１０は第１のアプリケーションソフトウエア４１６を実行するようにしてもよい。例を挙げると、第１のアプリケーションソフトウエア４１６には第２のファイルシステム４２０を修復するプログラム、又は第２のオペレーティングシステムイメージファイル４２４を復旧するプログラムを含んでもよい。

言い換えれば、本実施例のフラッシュメモリ４００を起動領域４０２、第１の領域４１２及び第２の領域４２２に仕切る。前記起動領域４０２には起動ファームウエア４０４が格納され、前記第１の領域４１２は第１のファイルシステム４１０にフォーマットされ、前記第２の領域４２２は第２のファイルシステム４２０にフォーマットされる。前記第１のファイルシステム４１０には１つの第１のオペレーティングシステムイメージファイル４１４及び１つの又は複数の第１のアプリケーションソフトウエア４１６が格納される。前記第２のファイルシステム４２０には１つの第２のオペレーティングシステムイメージファイル４２４及び１つの又は複数の第２のアプリケーションソフトウエア４２６が格納される。

さらなる実施例において、前記第１のオペレーティングシステムイメージファイル４１４は工場出荷時バージョンオペレーティングシステムを含み、前記第２のオペレーティングシステムイメージファイル４２４は運営バージョンオペレーティングシステムを含むことができる。

このような場合、工場出荷時バージョンが提供する第１のアプリケーションソフトウエア４１６は通常、基本機能、例えばファイルシステムを修復する又はオペレーティングシステムを復旧するためのツールプログラムのみ配置される。運営バージョンは複数の付加機能、例えばシステム動作データをリアルタイムに監視する、オンラインシームレスアップデート、暗号化モジュール等の複数の様々な第２のアプリケーションソフトウエア４２６を含むことができる。

したがって、前記第２のファイルシステム４２０の構成容量は通常、前記第１のファイルシステム４１０の容量よりも大きい。この他、工場出荷時バージョンは通常、バックアップシステムとされ、完全性をできるだけ維持しなければならないため、前記第１のファイルシステム４１０はリードオンリーモードでマウントされる。運営バージョンは頻繁な更新が許可されるため、第２のファイルシステム４２０はリード・ライトモードでマウントされる。

さらなる実施例において、第１の領域４１２及び第２の領域４２２はお互いのバックアップとなるよう同じコンテンツにすることができる。このような場合、前記第１のオペレーティングシステムイメージファイル４１４と前記第２のオペレーティングシステムイメージファイル４２４は同じバージョンである。

前記第２のファイルシステム４２０の容量と前記第１のファイルシステム４１０の容量は同じであり、且つどちらもリード・ライトモードでマウントされる。動作時に、そのうちの１つのファイルシステムが破損した場合又はオペレーティングシステムのアップグレードに失敗した場合、基板管理コントローラ３１０は他方のファイルシステムをマウントして動作を引き継ぎ、修復復旧を行う。

さらなる実施例において、前記第１のファイルシステム又は前記第２のファイルシステムはフラッシュメモリジャーナル型ファイルシステム(Journaling Flash File System；JFFS)である。

一方、前記第１のファイルシステム又は前記第２のファイルシステムは未ソートブロックイメージファイルシステム(Unsorted Block Image File System；UBIFS)でもよい。

図５は本出願の実施例の基板管理コントローラ３１０の起動フローチャートである。上記改良されたフラッシュメモリ４００アーキテクチャに基づいて行うステップは以下のようにまとめられる。ステップ５０１では、基板管理コントローラ３１０を起動する。ステップ５０３では、基板管理コントローラ３１０を起動又はリセットした後、基板管理コントローラ３１０のマイクロプロセッサ３２０はまずフラッシュメモリ４００から起動ファームウエア４０４を読み出して実行し、初期化プログラムを行い、これにはファイルシステムの駆動プログラムをロードし、ファイルシステムをマウントするための構成プロファイルを取得することを含む。前記構成プロファイルは１つのマウント装置テーブル(mount table)でもよい。

ステップ５０５では、基板管理コントローラ３１０は起動ファームウエア４０４に基づいて初期化を完了した後、構成プロファイルに基づき、第１のファイルシステム４１０又は第２のファイルシステム４２０をマウントすることを選択する。ステップ５０７では、マウントされた第１のファイルシステム４１０又は第２のファイルシステム４２０から第１のオペレーティングシステムイメージファイル４１４又は第２のオペレーティングシステムイメージファイル４２４を読み出して実行する。

ステップ５０９では、第１のオペレーティングシステムイメージファイル４１４又は第２のオペレーティングシステムイメージファイル４２４の起動成功後、第１のファイルシステム４１０又は第２のファイルシステム４２０から第１のアプリケーションソフトウエア４１６又は第２のアプリケーションソフトウエア４２６を読み出して実行する。

本実施例の利点の１つは、バックアップ機構を提供することにある。前記マイクロプロセッサ３２０は前記第１のファイルシステム４１０又は前記第２のファイルシステム４２０をマウントする時、マウントされたファイルシステムが破損している又はオペレーティングシステムイメージファイルが破損していることを発見した場合、バックアップされているファイルシステムをマウントし、バックアップされたオペレーティングシステムがロードされて基板管理コントローラ３１０の正常動作を維持することができる。さらに、バックアップされたオペレーティングシステムは元々破損した原因に対して修復プログラムを実行してもよい。

従来の一般的な基板管理コントローラのフラッシュメモリレイアウト及び起動手順に比べ、本発明は明らかな優位性を持つ：
本出願の基板管理コントローラのフラッシュメモリレイアウトの柔軟性は高い。従来のフラッシュメモリ１３０では、アドレスオフセット及びサイズの両方が予め決められていた。本実施例では、オペレーティングシステムのイメージファイルを、固定の仕切られたパーティション内ではなく、フラッシュメモリ４００のファイルシステムに格納する。こうすることで、フラッシュメモリのスペースを節約できるだけでなく、様々なサイズのファイルを収容することができる。

なお、本書において、技術用語“含む”、“包含する”又は、その他の如何なる代替語は非排他的な包含を網羅するため、一連の要素を含むプロセス、方法、物品又は装置はそれら要素を含む以外に、明示されていない他の要素をさらに含み、又はこのようなプロセス、方法、物品又は装置に固有の要素をさらに含む。

それ以上の限定がない場合において、用語“１つの……を含む”で限定される要素は、当該要素を含むプロセス、方法、物品又は装置の中に他の同じ要素がさらに存在することを排除するものではない。

以上、図面と合わせて本出願の実施例を説明した。しかし本出願は上記の実施の形態に限られるものではなく、上記の実施の形態は概略的なものであり、制限を加えるものではない。当業者であれば本出願の示唆により、本出願の思想及び請求項の保護範囲を逸脱しない限り、さらなる複数の形式を提供でき、これらも全て本出願の保護範囲内に入ると理解されるべきである。

Claims

起動ファームウエア、第１のオペレーティングシステムイメージファイル及び第１のアプリケーションソフトウエアが格納された第１のファイルシステム、及び第２のオペレーティングシステムイメージファイル及び第２のアプリケーションソフトウエアが格納された第２のファイルシステムを含むフラッシュメモリと、
前記フラッシュメモリに接続されたマイクロプロセッサと、
を備える基板管理コントローラであって、
起動時に、前記マイクロプロセッサが前記フラッシュメモリから前記起動ファームウエアをロードして実行し、
前記マイクロプロセッサは構成プロファイルに基づき、前記第１のファイルシステム又は前記第２のファイルシステムを選択的にマウントし、
前記マイクロプロセッサは前記第１のファイルシステム又は前記第２のファイルシステムに格納されたオペレーティングシステムイメージファイル及びアプリケーションソフトウエアをロードして実行することで、コンピュータシステムを制御する機能を実現する、ことを特徴とするコンピュータシステムを制御するための基板管理コントローラ。
前記フラッシュメモリは起動領域、第１の領域及び第２の領域に仕切られ、
前記起動領域は前記フラッシュメモリの最先端に位置し、前記起動ファームウエアを格納するために用いられ、
前記第１の領域は前記第１のファイルシステムにフォーマットされ、
前記第２の領域は前記第２のファイルシステムにフォーマットされ、
前記第２の領域の容量は前記第１の領域の容量以上である、
ことを特徴とする請求項１に記載の基板管理コントローラ。
前記第１のオペレーティングシステムイメージファイルは第１のバージョンオペレーティングシステムを含み、
前記第２のオペレーティングシステムイメージファイルは第２のバージョンオペレーティングシステムを含む、
ことを特徴とする請求項１に記載の基板管理コントローラ。
前記第１のバージョンオペレーティングシステムと前記第２のバージョンオペレーティングシステムは異なるバージョンであり、且つ、
前記第１のファイルシステムがマウントされる時、リードオンリーモードでマウントされ、
前記第２のファイルシステムがマウントされる時、リード・ライトモードでマウントされる、
ことを特徴とする請求項３に記載の基板管理コントローラ。
前記第１のバージョンオペレーティングシステムと前記第２のバージョンオペレーティングシステムは同じバージョンであり、且つ、
前記第１のファイルシステム又は前記第２のファイルシステムがマウントされる時、リード・ライトモードでマウントされる、
ことを特徴とする請求項３に記載の基板管理コントローラ。
前記第１のファイルシステムはフラッシュメモリジャーナル型ファイルシステム又は未ソートブロックイメージファイルシステムであり、
前記第２のファイルシステムはフラッシュメモリジャーナル型ファイルシステム又は未ソートブロックイメージファイルシステムである、
ことを特徴とする請求項１に記載の基板管理コントローラ。
前記マイクロプロセッサは前記第１のファイルシステム又は前記第２のファイルシステムの一方をマウントする時、マウントされた前記第１のファイルシステム又は前記第２のファイルシステムが破損していることを発見した場合、前記第１のファイルシステム及び前記第２のファイルシステムのうち破損していない他方をマウントする、
ことを特徴とする請求項１に記載の基板管理コントローラ。
前記マイクロプロセッサは、前記第１のファイルシステム及び前記第２のファイルシステムのうち破損していない他方をマウントした後、前記ファイルシステムの破損を修復するためのリカバリプログラムを実行する、
ことを特徴とする請求項７に記載の基板管理コントローラ。
基板管理コントローラを備え、
前記基板管理コントローラにより制御され、起動、シャットダウン、リセット、システムファームウエアアップグレード、及び実行データ監視のうち少なくとも１つの機能を実行する、コンピュータシステムであって、
前記基板管理コントローラは、起動ファームウエア、第１のオペレーティングシステムイメージファイル及び第１のアプリケーションソフトウエアが格納された第１のファイルシステム、及び第２のオペレーティングシステムイメージファイル及び第２のアプリケーションソフトウエアが格納された第２のファイルシステムを含むフラッシュメモリと、
前記フラッシュメモリに接続されたマイクロプロセッサと、
を備え、
前記基板管理コントローラの起動時に、前記マイクロプロセッサが前記フラッシュメモリから前記起動ファームウエアをロードして実行し、
前記マイクロプロセッサは構成プロファイルに基づき、前記第１のファイルシステム又は前記第２のファイルシステムを選択的にマウントし、
前記マイクロプロセッサは前記第１のファイルシステム又は前記第２のファイルシステムに格納されたオペレーティングシステムイメージファイル及びアプリケーションソフトウエアをロードして実行することで、コンピュータシステムを制御する機能を実現する、ことを特徴とするコンピュータシステム。
起動ファームウエア、第１のオペレーティングシステムイメージファイル及び第１のアプリケーションソフトウエアが格納された第１のファイルシステム、及び第２のオペレーティングシステムイメージファイル及び第２のアプリケーションソフトウエアが格納された第２のファイルシステムを含むフラッシュメモリと、
前記フラッシュメモリに接続されたマイクロプロセッサと、
を備える基板管理コントローラに適用可能な基板管理コントローラの起動方法であって、
前記基板管理コントローラの起動時に、起動領域から前記起動ファームウエアをロードして実行するステップと、
構成プロファイルに基づき、第１のファイルシステム又は第２のファイルシステムを選択的にマウントするステップと、
前記第１のファイルシステム又は前記第２のファイルシステムに格納されたオペレーティングシステムイメージファイル及びアプリケーションソフトウエアをロードして実行することで、コンピュータシステムを制御するステップと、
を含む、
ことを特徴とする基板管理コントローラの起動方法。
前記第１のファイルシステム又は前記第２のファイルシステムの一方をマウントする時、マウントされた前記第１のファイルシステム又は前記第２のファイルシステムが破損していることを発見した場合、前記第１のファイルシステム及び前記第２のファイルシステムのうち破損していない他方をマウントするステップをさらに含む、
ことを特徴とする請求項１０に記載の基板管理コントローラの起動方法。
前記第１のファイルシステム及び前記第２のファイルシステムのうち破損していない他方をマウントした後、前記ファイルシステムの破損を修復するためのリカバリプログラムを実行するステップをさらに含む、
ことを特徴とする請求項１１に記載の基板管理コントローラの起動方法。
前記フラッシュメモリを起動領域、第１の領域及び第２の領域に仕切るステップと、
前記起動領域を利用して、前記起動ファームウエアを格納するステップと、
前記第１の領域を前記第１のファイルシステムにフォーマットするステップと、
前記第２の領域を前記第２のファイルシステムにフォーマットするステップと、
をさらに含み、
前記起動領域は、前記フラッシュメモリの最先端に位置し、
前記第２の領域の容量は前記第１の領域の容量以上である、
ことを特徴とする請求項１０に記載の基板管理コントローラの起動方法。
前記第１のオペレーティングシステムイメージファイルは第１のバージョンオペレーティングシステムを含み、
前記第２のオペレーティングシステムイメージファイルは第２のバージョンオペレーティングシステムを含む、
ことを特徴とする請求項１０に記載の基板管理コントローラの起動方法。
前記第１のバージョンオペレーティングシステムと前記第２のバージョンオペレーティングシステムは異なるバージョンであり、
前記第１のファイルシステムをマウントするステップは、リードオンリーモードでマウントされることを含み、
前記第２のファイルシステムをマウントするステップは、リード・ライトモードでマウントされることを含む、
ことを特徴とする請求項１４に記載の基板管理コントローラの起動方法。
前記第１のバージョンオペレーティングシステムと前記第２のバージョンオペレーティングシステムは同じバージョンであり、
前記第１のファイルシステムをマウントするステップは、リード・ライトモードでマウントされることを含み、
前記第２のファイルシステムをマウントするステップは、リード・ライトモードでマウントされることを含む、
ことを特徴とする請求項１４に記載の基板管理コントローラの起動方法。
前記第１のファイルシステムはフラッシュメモリジャーナル型ファイルシステム又は未ソートブロックイメージファイルシステムであり、
前記第２のファイルシステムはフラッシュメモリジャーナル型ファイルシステム又は未ソートブロックイメージファイルシステムである、
ことを特徴とする請求項１０に記載の基板管理コントローラの起動方法。