beaglebone black的cape管理

BBB的cape是如何管理的呢？如下引用「魏來之路」網友的說明，說的很詳細：

「Beaglebone Black中用一個叫作capemgr的軟件管理全部的cape，不論它是實實在在的擴展板，仍是虛擬的cape。這個軟件的目錄是/sys/devices/bone_capemgr.*/（這裏的*是一個每次系統啓動可能會不同的數字（與啓動順序有關））」

參考網址：http://blog.csdn.net/wyt2013/article/details/16846171

從官方的一個WIKI中有詳細的說明，也說明了CAPE和DT及Kernel的關係：「BeagleBone and the 3.8 Kernel」（http://elinux.org/BeagleBone_and_the_3.8_Kernel#Cape_Manager_requirements）。

我將其中的關於capemgr，比較重要的翻譯了一下。

 1: Cape Manager requirements

 2: 

 3: Going over the device tree definition we see that the data structure is referred as parsed at boot-time. Beaglebone capes are not static; a different cape set might be connected each time the board boots, and the only way to find out what kind of cape is connected is to read the serial EEPROM present on each cape which contains identification information.

 4: 

 5: Beaglebone capes are mostly compatible between White and Black, but due to the presence of the eMMC flash and the HDMI framer, some special attention must be paid for capes that use the same resources.

 6: 

 7: The information stored on the EEPROM of each cape are a user readable name, serial number, part number, revision information and others. The only information that the cape manager uses to work are the part-number and the revision.

 8: 

 9: A cape-manager should perform the following:

 10: 

 11: Scan the I2C bus for EEPROMs that correspond to the address defined in the beaglebone SRM. Those addresses are 0x54-0x57 on I2C1 bus, hence the 4 capes limitation.

 12: Read the EEPROM contents and parse them according to the spec. Retrieve the part-number and revision information of that cape.

 13: Match the PART-NUMBER:REVISION tuple to a configuration that would result in the system state being that as if the cape was directly attached to the base board, and perform any actions that result to it.

 14: Additionally we need extra facilities that are useful for people developing capes:

 15: 

 16: An override facility so that prototyping capes with no EEPROM can be supported.

 17: An option to load capes at runtime.

 18: An option to unload capes at runtime.

 19: An option to stop a cape from loading even if detected.

 20: To guard against resource conflicts. A cape that uses the same resources as another loaded earlier should not be permitted to load.

 21: To be able to forbid cape loading of capes that are not supported by a baseboard revision.

 22: To be able to load 'virtual' capes that correspond to peripheral that are present on specific baseboard revisions.

 23: To support the notion of a cape priority, so that in case of a conflict, the cape we define as higher priority gets loaded. This is important to allow plug in capes to take preference over capes that are part of the baseboard; i.e. when an LCD cape is attached it takes preference over the onboard HDMI virtual cape.

 24: To not require source changes for any driver for a peripheral that resides on cape or onboard , i.e. the drivers should not be modified for use in a cape.

 25: No kernel source changes must be required for a new cape to be supported.

 26: To not require modification of the boot-loader, or of the base DTS.

縱觀DT的定義，咱們瞭解到DT的數據結構是在系統啓動的時候載入的，而BB的cape卻不是靜態的，不一樣的cape可能在不一樣的時候接入系統，並且只有經過讀取每一個cape上的E2PROM的信息才能肯定cape的種類，這個識別信息是預置於E2PROM中的。

BBB的cape一般與BBW/BBB是兼容的，可是由於BBB內置的eMMC和HDMI功能，使用與其相同資源的cape須要特別予以注意，避免出現資源衝突。

每一個cape中E2PROM的存儲的信息主要有名稱、序列號、產品號、版本信息及其它內容，而cape的管理器(capemgr）每每使用其中的產品號和版本號。

Capemgr的工做流程以下：

１、掃描I2C總線的E2PROM（其地址範圍參照SRM的規定），地址範圍爲0x54-0x57，端口爲I2C1，所以可以使用４個cape。

２、讀取E2PROM的內容，而且經過其中的part-number和revision信息對其進行識別。

３、經過PART-NUMBER:REVISION的組合，尋找相信的配置信息，而且執行（配置信息中）相應的「規定」動做。

此外，capemagr還支持一些特殊的功能，便於你們開發cape:

a) 可超越控制（手動控制）：用於支持無E2PROM的cape原型。

b) 運行時可載入。

c) 運行時可卸載。

d) 即使它已經被系統到也能夠中止載入。

e) 防止資源衝突。不一樣的cape使用相同的資源時，先到先得。

f) 具有載入虛擬cape的功能（預置於baseboard的，如eMMC等）

g) 防止不支持的cape載入。

h) 支持cape的優先級，當出現衝突時，高優先級的可載入。

i) 不須要改變板載資源或cape的源代碼。

j) 增長新cape支持時，無需改變Kernel源代碼。

k)無需改變boot-loader或基本的DTS