'/sys/devices/bone_capemgr.*/slots': No such file or directory

[monomente]

I am trying to get started with the CRAMPS tree overlay. My kernel version from /boot/uEnv.txt is uname_r=4.19.94-ti-r42

When I run sudo./start-devicetree-overlay.sh CRAMPS/BeagleG-CRAMPS.dts I get the following output:

`make: 'CRAMPS/BeagleG-CRAMPS-00A0.dtbo' is up to date.

Adding BeagleG-CRAMPS overlay
./start-devicetree-overlay.sh: line 69: /sys/devices/bone_capemgr.*/slots: No such file or directory
cat: '/sys/devices/bone_capemgr.*/slots': No such file or directory`

It seems that the bone_capemgr directory is no longer present. It seems that for newer kernel versions the we might not compile and load the device tree overlays in this way. I will try to read more to understand how this updated process works but wondering if someone else has had this issue.

[hzeller]

Yes, the Beaglebone has changed these things around a little in recent years; also the software interface to the PRU needs to be adapted.

I kept the operating system version on my 'production' BeagleG CNC machines so things might be a bit 'crusty' depending on older Kernels.. In paritcular I found that at some point the whole software interface to the PRU (formly uio_pruss) just got more compilcated than needed so I didn't bother chasing the interface change.

Having said that, getting BeagleG working on a modern kernel on a Beaglebone would be highly appreciated, and we're ready to accept a pull request for that. Possibly the folks over at https://forum.beagleboard.org/ might be able to give a hand. Jason Kridner @jadonk (say hi!) might know someone who can help converting old cape definitions and PRU PRUSS interface to whatever is current today.

(Currently I am working on some more platform independent version of BeagleG that will also run on other platforms).

[jadonk]

Yeah, I'd love to answer a few questions to help this along!

[hzeller]

Thanks for chiming in Jason!

As you know, BeagleG is a few years old now, and I have it running on my home CNC machines (and soon also my laser cutter), but the kernel interfaces to the hardware changed over time and while I was waiting for things to settle, I just pinned some older version on my Beagleboards. Bringing this up to a state that it is usable for a current operating system would be the goal.

There are mostly two toplevel questions (at this point):

• We have device tree overlay files that are by now a few years old, such as the BUMPS overlay or the CRAMPS overlay. For these we havescripts install-devicetree-overlay.sh and start-devicetree-overlay.sh that are by this time not really working anymore in the current system (as I said, I had pinned my OS version at some point, so never got around fixing this). So question here: is there a guide somewhere how to convert these things to modern times ? Or someone who can do that easily and help putting together a pull request ?
• The PRU interface. In preparation for the remoteproc change, the code to interact with the PRU is already abstracted as interface, however the only implementation is still based on UIO, which was the original native way to interface with the PRU, but these days that needs to be based on remoteproc. For someone familiar with these, that is probably also not too complicated to add a new implementation based on RemoteProc (note the PRU code is written in assembly which is loaded plain via an array into the UIO interface, not sure if this needs different linking options in the remote-proc case).

[monomente]

Thanks for your reply! Even though it is a few years old, I think BeagleG is still quite relevant in terms of what is available for open-source CNC applications. I was able to clone the repo and compile successfully, but ran into issues with the device overlay script and not understanding how to properly edit the /boot/uEnv.txt to accept the CRAMPS .dtbo file that I compile myself.

I am not using a cape at the moment. I wanted to use existing device tree overlay for use with my external DM542 NEMA23 drivers (wired via a level shifter IC). I think it could be a common use-case that people to want to use these bigger drivers for CNC, not necessarily using a cape.

I just got a copy of Derek Molloy's book on the Beaglebone as I'm pretty new to embedded linux. I think I can make some progress on getting the device tree overlay process updated, particularly if I ask on the Beaglebone forum. Not so sure on the PRU interface however or how much of the code needs to be modified.

[hzeller]

Yes, I have heard from people using BeagleG successfully with a Xylotex db25 cape that plugs on a Beaglebone and outputs a level-shifted signal on a DB25 connector, often used in CNC machines, but I am not sure if they still sell it. But something like that is quick to make.

[hzeller]

Hey @jadonk - do you know someone who can help with these questions ?

[jadonk]

What is your objective? Can I help you get to a newer baseline?

[hzeller]

Objective is to get BeagleG running on a fresh operating sytem install on a Beaglebone. It uses the UIO interface with the PRU, but these days, things are done with remoteproc. That probably needs to be converted. Also, the cape manager does seem to be different these days (see title of this issue).

So my personal objective is to get this going on a current operating system while avoiding pitfalls due to finding conflicting old and new information on the 'net by asking someone who knows the current state of the art who can guide or provide pull requests to get this to the latest state.

[hzeller]

So there are two parts to this

• Get all hardware mappings use the universal pin mapping. This is already done in the VGEN5 and BUMPS with the *.pins file, and probably will not be too complicated. The most comprehensive description how to set up things to get started would be in the VGEN5 directory. Overall, this should be pretty straight-forward to get going with CRAMPS. This will simplify the whole thing and we don't need the more complicated device overlay thing.
• The other thing is: how to get the prussdrv converted to remoteproc. We created a *bin.h file from the *.p file, so the PRUCode is already available as array, we just need to adapt what we have in uio-pruss-interface.cc to load and start the code in the 'remoteproc' way. I hope that @jadonk has a link somewhere describing how to do that (I'd be happy if pruss would still be available in recent kernels, but since they're not, we do have to do the remoteproc conversion :/ ).

[hzeller]

I've ordered a CRAMPS board, so that I can test with it.

[jadonk]

Cool. If you want to get on the latest images, come on to the Slack (bbb.io/gsocmeet) and work with rcn-ee and myself. Also, we have a 3d printing channel that is just getting started.

[hzeller]

Good news:

• With current kernels, the UIO-PRUSS interface is still working, if the bone kernel is installed. I've updated the install file to describe what is necessary. That way, we don't have to switch to the remoteproc thing.
• changed BUMPS board to use config-pin utility from the universal IO and it works fine. As soon as I receive a CRAMPS board, will update that old overlay to use the universal IO as well.

Getting closer.