CapeMgr in 3.13?

Is the CapeMgr in the 3.13 kernel series?

I installed Debian wheezy via the eMMC flasher script and then upgraded to 3.13 (http://rcn-ee.net/deb/wheezy-armhf/v3.13.2-bone5/).

However, I don’t see the capemgr in /sys/devices nor any message in dmesg:

ls /sys/devices/
44e10800.pinmux breakpoint hdmi.9 ocp.3 pmu.0 soc.1 system virtual
ARMv7 Cortex-A8 fixedregulator.8 leds.7 platform soc0 software tracepoint

Is this supposed to be case? If so, what is the paradigm to do things like this:

echo am33xx_pwm > $SLOTS
echo bone_pwm_P8_13 > $SLOTS

(where SLOTS=/sys/devices/bone_capemgr.8/slots)

Thanks,

Josh

Hi Josh,

no, in the current 3.13 images available from Robert Nelson there is no cape manager.

He started a project “Really Simple Cape Manager” https://github.com/RobertCNelson/rscm that changes the hardware configuration by patching the device tree source file “am335x-boneblack.dts”, builds it and then copies it to the boot partition. So there are no more device tree overlays.

I like this solution and in my projects the hardware configuration is fixed and will not be changed during runtime.

In the “simple” folder there are some examples patch files.

Best regards,
Michael

#shamelessplug

I haven't tested with the 3.13 kernel, but this sounds like a good use
for my "universal" device tree overlay, which lets you setup and use
most of the hardware from user-space:

https://github.com/cdsteinkuehler/beaglebone-universal-io

You can switch pins between various functions like pwm, uart, and gpio
using a static device tree and entries in sysfs.

I've got a script[1] that makes this easy, so you can do things like:

./config-cape-universal P8.13 pwm
./config-cape-universal P9.24 uart
./config-cape-universal P9.26 high

The advantage of defining all the hardware in the same "overlay" is you
can mix and match pins, for instance using just the Tx or Rx side of the
UART, while using the other pin for a different function without having
to custom edit your own device tree file.

[1] Yes, config-cape-universal is a lousy name. Suggestions for a
better name are welcome!

Hi Charles,

I haven’t tested with the 3.13 kernel, but this sounds like a good use
for my “universal” device tree overlay,

As far as I can see your “universal” device tree overlay expects to find

/sys/devices/bone_capemgr.*/slots 

which seems to be gone in 3.13.x

Regards,

Robert

Are you up for porting it from v3.8 and maintaining it? :wink:

Regards,

Hi,

As far as I can see your “universal” device tree overlay expects to find

/sys/devices/bone_capemgr.*/slots 

which seems to be gone in 3.13.x

Are you up for porting it from v3.8 and maintaining it? :wink:

Not me, so I am looking for some solution which is not a dead end;)

… but somehow Derek seems to have a 3.13 kernel running on a bone with capemgr.[1][2]

Regards,

Robert

[1] http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
[2] https://github.com/derekmolloy/boneDeviceTree

Where does it state he is running on 3.13, I seem to be missing it ?

Hi Charles,

I haven't tested with the 3.13 kernel, but this sounds like a good use
for my "universal" device tree overlay,

As far as I can see your "universal" device tree overlay expects to find

/sys/devices/bone_capemgr.*/slots

which seems to be gone in 3.13.x

That's just to make sure the overlay is loaded. There are no overlays
(yet?) in 3.13.

Are you up for porting it from v3.8 and maintaining it? :wink:

I'm game if it actually gets used. There should be little or no
difference between 3.8 and 3.13 as long as the pinmux-helper and
gpio-of-helper are available. And they should be easy to port if not.

Hi,

Where does it state he is running on 3.13, I seem to be missing it ?

Sorry - to many thirteen s - it’s 3.8.13 :wink:

https://github.com/derekmolloy/boneDeviceTree/tree/master/DTSource3.8.13

Regards,

Robert

Figured that was the one :slight_smile:

Charles,

Personally, I think the other idea you had ( default device tree overlay ? ) is a better idea. It is kind of the same thing, but perhaps no dynamic loading while the OS is live. Which in my humble opinion was never a good idea anyhow( live pin-muxing ).

I'm confused, what exactly do you mean?

My idea is basically to enable as much useful SoC hardware as practical
via a single device tree overlay or via a static device tree (on kernels
without the cape manager). The pinmux helper module then allows
run-time selection of the hardware you want to use for any given pin.

There's no way to avoid playing with the pin multiplexers when the OS is
"live" other than by editing the device tree and reloading. That's the
problem I'm trying to get around...allowing run-time selection of
hardware without having to understand or compile device tree fragments.

Charles,

Ok, my bad I think I confused what you’re trying to do with what I personally would do.

With that said, I can not speak for anyone else, but I would find a cape manage for 3.13.x useful. In fact not having a way to load a device tree file via uEnv.txt as with 3.8.x is what is primarily keeping me from using 3.13.x for the time being. Really, I like some of how 3.13.x is right now ( hard code a device tree overlay it seems ), but short term, I do not have time to learn how this works. Too many irons, and not enough fires . . . or something like that :wink: