help using uio_pruss with 4.4.30-ti-64

[ags]

uname -a

Linux BBBr0C0-1 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l GNU/Linux

I am trying to use uio_pruss driver with PRUs. I have been able to make them work "the old way" with 3.8 kernel, which (IIRC) used brute-force /dev/mem and interrupts exposed through /dev/uio*.

I have loaded the PRU cape to enable the PRUs. I have confirmed that I have loaded the uio_pruss.ko

I still don't see any uio* devices.

Is there a "how-to" for the 4.4-ti kernel? I've read extensively here, but not found definitive answers. It seems much of the content is in debating the pros/cons of the remoteproc/uio differences.

My application will require reading data from eMMC/SDcard (ARM core/userspace) and sending to PRUs for bitbanging output. I plan to have the PRU use interrupts to indicate readiness for more data (in PRU shared memory). Based on what I've read, this is a good application for the uio drivers.

Any help/pointers to information that is current/usable for the 4.4-ti build would be greatly appreciated.

[neil...@gmail.com]

I had similar issues trying to get uio_pruss to work on my BBB...

   Linux beaglebone 4.4.36-ti-r72 #1 SMP Wed Dec 7 22:29:53 UTC 2016 armv7l GNU/Linux (bone-debian-8.6-iot-armhf-2016-12-09-4gb.img)

I found the below steps useful.

   https://groups.google.com/d/msg/beagleboard/l59Dx8ygxNg/GvIzOJSzDAAJ

HTH

[Robert Nelson]

Just use the v4.4.x-bone kernel:

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh --bone-kernel --lts-4_4

uio_pruss is enabled by default, it's up to you to load the overlay
with the pinmux'ing...

Regards,

--
Robert Nelson
https://rcn-ee.com/

[A H]

Hi, Robert thanks for your reply. I'm also on the exactly same situation, I follow the steps here: https://groups.google.com/forum/#!msg/beagleboard/l59Dx8ygxNg/GvIzOJSzDAAJ

and dmesg, lsmod show that pruss_uio driver is loaded but /sys/class/uio directory is still empty and I still get the error "prussdrv_open open failed" when I run my example code. [https://github.com/osresearch/LEDscape]

Could you please elaborate on what do you mean by "loading overlay manually". Do you mean the "echo BBXXXX > /sys/devices/platform/bone_capemgr/slots" command?

[Robert Nelson]

On Thu, Mar 2, 2017 at 4:16 PM, A H <asad...@gmail.com> wrote:
> Hi, Robert thanks for your reply. I'm also on the exactly same situation, I
> follow the steps here:
> https://groups.google.com/forum/#!msg/beagleboard/l59Dx8ygxNg/GvIzOJSzDAAJ
>
> and dmesg, lsmod show that pruss_uio driver is loaded but /sys/class/uio
> directory is still empty and I still get the error "prussdrv_open open
> failed" when I run my example code. [https://github.com/osresearch/LEDscape]
>
> Could you please elaborate on what do you mean by "loading overlay
> manually". Do you mean the "echo BBXXXX >
> /sys/devices/platform/bone_capemgr/slots" command?

Yes, and make sure you have the pinmux setup in BBXXXX

[ags]

Robert, my hope is to learn through doing, and eventually have enough understanding of dt and enabling LKM/drivers so that I can maintain what I develop through kernel updates and the inevitable progress that will continue. So it's not just about getting things to work.

Would you kindly provide guidance, or point me to documentation I can study to understand the differences between the ti and bone kernels? Specifically, if there is information on how I can enable the uio_pruss driver that would be a good start.

I'm trying to take small steps. The first was simple /dev/mem and mmap() interface to PRUSS. I realize that I won't be able to get interrupts this way, but it's a first step validating my understanding (not relying on "driver magic"). What I'm seeing is that I cannot even read/write to the PRUSS data ram or shared ram. Searching on the error log messages seems to indicate the problem is that the PRUSS clock needs to be enabled. (I think). I suspect this is part of what the uio_pruss driver does?

Thanks.

[ags]

@RobertCNelson

I found and followed (mostly) the instructions you previously provided here: https://groups.google.com/forum/#!msg/beagleboard/l59Dx8ygxNg/GvIzOJSzDAAJ

and I am now able to mmap the PRU memory and read/write to it. Loading PRU instructions comes next, and then finally pinmuxing and bit-banging.

I believe it is the uio_pruss driver that creates the /dev/uio<n> devices, which are necessary to be able to respond to interrupts from the PRU (correct me if this wrong).

However, I don't think this prevented me from accessing the PRU memory resources though (?). I searched on the system error messages received before I properly enabled the PRUSS and there was discussion of them resulting from not having clocks enabled.

I'm assuming that another effect of enabling the PRUSS in the dt is enabling the clocks. I see an  pruss_ocp_gclk child node in the l4_wkup@44c00000 node. Is there another way to enable the clocks through the device tree?

Finally, following the directions above was close to what I had been trying to do on my own (except I was not blacklisting the remoteproc drivers, another problem). When I tried to compile the dts I had created, dtc complained about not being able to parse the dts file. So I ended up cloning your dtb-rebuilder repo - but I have no idea why it was needed. I had exactly the same *.dts files and had made mostly the same changes (instead of including a *.dtsi to enable the PRUSS, I had done so inline in my version of the am335x-boneblack.dts). So I tried building a dtb file from the same source as make used in the dtb-rebuilder install - and it also gave the same error.

So why is dtb-rebuilder needed, and what is the "magic" that's happening to have dtc parse the dts files?

BTW, I did not move to the bone kernel but stayed wit the ti kernel. Not sure what the differences are between them.

On Thursday, March 2, 2017 at 9:04:52 AM UTC-8, RobertCNelson wrote: