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，比较重要的翻译了一下。

Cape Manager requirements

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.

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.

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.

A cape-manager should perform the following:

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.
Read the EEPROM contents and parse them according to the spec. Retrieve the part-number and revision information of that cape.
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.
Additionally we need extra facilities that are useful for people developing capes:

An override facility so that prototyping capes with no EEPROM can be supported.
An option to load capes at runtime.
An option to unload capes at runtime.
An option to stop a cape from loading even if detected.
To guard against resource conflicts. A cape that uses the same resources as another loaded earlier should not be permitted to load.
To be able to forbid cape loading of capes that are not supported by a baseboard revision.
To be able to load 'virtual' capes that correspond to peripheral that are present on specific baseboard revisions.
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.
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.
No kernel source changes must be required for a new cape to be supported.
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