CapeMgr in 3.13?

[Joshua Datko]

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

[Michael]

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

[Charles Steinkuehler]

#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!

--
Charles Steinkuehler
cha...@steinkuehler.net

[robert.berger]

Hi Charles,

On Sunday, February 9, 2014 6:56:41 AM UTC+2, Charles Steinkuehler wrote:

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

[Robert Nelson]

Are you up for porting it from v3.8 and maintaining it? ;)

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[robert.berger]

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? ;)

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

[Don deJuan]

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Charles Steinkuehler]

On 2/10/2014 10:10 AM, Robert Nelson wrote:
> On Mon, Feb 10, 2014 at 10:08 AM, robert.berger <
> robert.ka...@gmail.com> wrote:
>
>> Hi Charles,
>>
>>
>> On Sunday, February 9, 2014 6:56:41 AM UTC+2, Charles Steinkuehler wrote:
>>>
>>>
>>> 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? ;)

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.

--
Charles Steinkuehler
cha...@steinkuehler.net

[robert.berger]

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 ;)

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

Regards,

Robert

[Don deJuan]

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Figured that was the one :)

[William Hermans]

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 ).

[Charles Steinkuehler]

On 2/10/2014 3:23 PM, William Hermans wrote:
> 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 Steinkuehler
cha...@steinkuehler.net

[William Hermans]

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 ;)

--
Charles Steinkuehler
cha...@steinkuehler.net