Shutting Down PRUs via RemoteProc Framework from user-space?

[Greg]

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.

Regards,

Greg

[William Hermans]

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

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e12d6e11-3d19-469f-83bb-71f69922f125%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Reeder]

Greg,

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:

cat /sys/kernel/debug/remoteproc/remoteproc1/name

You can dump some control registers (CTRL, Program Counter, etc.) while the PRU is running by reading the 'regs' file:

cat /sys/kernel/debug/remoteproc/remoteproc1/regs

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

cat /sys/kernel/debug/remoteproc/remoteproc1/regs

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

Jason Reeder

[Greg]

Hi Jason-

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.

[Greg]

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.

[William Hermans]

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.

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/7bf54826-24ec-465b-a3d7-22dc5337ddff%40googlegroups.com.