"Beaglebone and the 3.8 Kernel"

Hi

I'm the author of that document. Glad that you've found it helpful.

As to why it's not available from beagleboard.org and circuitco wiki, it is being rectified right now.

Had to have a few review cycles before it went out.

The problem with working on the cutting edge is that stuff just haven't got around to be documented

thoroughly, so for new comers it sure is indimidating at first.

We're also working on getting some examples of using the standard peripherals on the next release,

which will help people get their designs working much faster.

Don't hesitate to ask for more information, or to point areas that the document needs help.

Hi Pantelis,

We really do understand just how new this stuff is, so thankyou for the doc. It really helps.

If you have time, I have one question..  Suppose I wanted to access the userspace overlay loading support from something like a Raspberry Pi (or Sabre-Lite, Cubieboard, Wandboard etc), am I able to do that with your current code ?  

As far as I can tell it's only exposed through the beaglebone cape manager currently, but I can think of lots of scenarios where I wouldn't have the cape manager (or simply wouldn't want it) but the base overlay loading feature could be really useful.

Prototyping capes generally don't have the eeprom describing the cape, so the expected answer is (probably) that it can be done manually, not just through the cape manager.  Other boards don't have capes anyway, and DT is intended as a board- and architecture-independent technology.   Also, even in the presence of capes, one would still want the ability to override the cape manager's operation in some cases, for a subset of the capes currently present perhaps.

Confirmation that this is the intended direction of development would be very useful.

Prototyping capes generally don't have the eeprom describing the cape, so the expected answer is (probably) that it can be done manually, not just through the cape manager.  Other boards don't have capes anyway, and DT is intended as a board- and architecture-independent technology.   Also, even in the presence of capes, one would still want the ability to override the cape manager's operation in some cases, for a subset of the capes currently present perhaps.

Confirmation that this is the intended direction of development would be very useful.

All of the use cases you have mentioned are already handled.

1) Prototyping capes can be override-loaded via three methods; kernel command line, base DT file override and runtime loading.

2) A command line option disables automatic loading of matching capes.

3) Virtual capes are already included which provide canned peripheral configuration for various cases, i.e. standard setup for UART/I2C/SPI/ADC and others. There's nothing that ties the cape manager to only the external connectors.

Hope this clear enough.

That's a very concise description of your coverage of the problem space, and covers all my existing questions.

Many thanks!