Hello, a quick question on operating PRUs via the RemoteProc framework on Beaglebone:
Is there a command via RemoteProc which will stop execution of firmwares running on the PRU(s)?
There are bind and unbind capability in sys:
echo “4a334000.pru0” > /sys/bus/platform/drivers/pru-rproc/bind
echo “4a338000.pru1” > /sys/bus/platform/drivers/pru-rproc/bind
echo “4a334000.pru0” > /sys/bus/platform/drivers/pru-rproc/unbind
echo “4a338000.pru1” > /sys/bus/platform/drivers/pru-rproc/unbind
The unbind appears to disconnect RPMsg (character devices gone), but it does not halt the PRU!
So after unbind, I am doing this:
sudo rmmod pru_rproc
sudo rmmod pruss
So after removing pruss the PRUs appear to halt.
So that is a total of 3 commands to halt a PRU.
So what I am looking for is a RemoteProc framework capability to halt the PRU(s) from user-space.
If there is none, I will use the rmmod commands as above. I’m hoping I am missing a simpler method.
Greg, have you read the remoteproc kernel documentation ? I did like a year ago, and I do want to say there is a method to halt remoteproc. But I’m not sure, and even if I did read that. There is no telling if it’s actually been implemented yet into our kernel / kernel modules . . .
Suman added a simple debug interface for remoteproc at ‘/sys/kernel/debug/remoteproc/’.
On the BBB (AM335x) there are three devices available at that folder: remoteproc0 (the wakeup M3 core), remoteproc1 (PRU0), and remoteproc2 (PRU1). You can verify which is which by the ‘name’ file in each folder:
You can dump some control registers (CTRL, Program Counter, etc.) while the PRU is running by reading the ‘regs’ file:
To halt a PRU, write a 1 to the single_step file. This will halt the PRU and allow you to dump the full register set:
echo 1 > /sys/kernel/debug/remoteproc/remoteproc1/single_step
You can continue single stepping through code and dumping the registers by repeating the two lines above.
To run the PRU core again just write a 0 to the single_step file:
echo 0 > /sys/kernel/debug/remoteproc/remoteproc1/single_step
I just tried it out with the PRU PID Motor controller example I have running here.
Regarding this command:
echo 1 > /sys/kernel/debug/remoteproc/remoteproc2/single_step
Does this halt the PRU1 core only?
I am looking for a complete shutdown of the PRU. Go to sleep including peripherals.
I think what I am seeing is that the PRU core halts, but the PRU peripheral keeps going.
The PRU PID example uses the PWM on the PRU.
So even after issuing the above command, the PWM keeps on going!
However, I can tell the core is shut down because it no longer responds to commands to change the PID setpoint.
Then after echo 0 > single_step it starts responding to commands again. But the PWM never shut down.
I can of course change the setpoint to zero before halting the core.
I guess what I am looking for is the cleanest method of putting the core to sleep and reducing power consumption.
Also I am thinking about how to to an emergency shutdown of a mechanical device.
I’m new to embedded systems design. I think this is a reasonable requirement for the system?
Just not sure the best way to do this or status of current thinking in embedded systems design.
That’s a good idea…I did that earlier this year when I understood the workings of the kernel much less.
I don’t think I made any progress figuring out how user-space access gets exported to virtual file system at /sys.
Will do some grepping on the kernel sources and drill into the documentation and see what I can come up with.
There is some fantastic stuff at free-electrons.com, but it is much material!
I’m wrapping up some documentation, want to get it done, RemoteProc shutdown is a secondary issue so I will put it on the backburner until I have another look at the kernel.
I typically search the web with a keyword like “Documentation/remoteproc”, and if documentation exists I’ll usually find it right away. ----> https://www.kernel.org/doc/Documentation/remoteproc.txt. Then I’ll check free-electrons site if I think the documentation may be different between kernels. Since on their web site, you can look at source files, and documentation for different kernel versions. Which often times can be different from source and occasionally documentation one may download from linus’ tree patched for our board here . . . So I tend to start off with the documentation in Linus’ tree, then keep looking if, and when I need to - Afterwards.