[BBB] Enable PRU on Beaglebone Black

This forum is for supported devices using an ARMv7 Texas Instruments (TI) SoC.

[BBB] Enable PRU on Beaglebone Black

Postby Wesman26 » Fri Oct 19, 2018 7:53 pm

Howdy folks,

I'm trying to enable the PRUs on my BBB, and I'm struggling to understand what I need to do.

A lot of the information I'm finding out in the wild is outdated, going as far back as kernel version 3.8. I have a fresh install of Archlinux ARM on my board and I'm running kernel 4.18.9-1. I assume things haven't changed overly much from kernel 4.14, but if I need to change to an older version I can.

I've read through this thread and this thread and found the answers from summers to be particularly helpful, but even they are a few months old and rely on older kernels, and most importantly neither one seems to focus on enabling the PRUs to be used as MCUs.

Can anybody help me? Are there resources I've missed? Will I need to revert to an older kernel? Will I need to write a custom device tree blob?

Any help would be greatly appreciated,
--W
Wesman26
 
Posts: 58
Joined: Mon Feb 06, 2012 2:08 am

Re: [BBB] Enable PRU on Beaglebone Black

Postby Wesman26 » Sat Oct 20, 2018 12:33 am

Alright, so with some help from summers I was able to figure some things out. It would appear that the process is very similar to the one listed in the SPI thread linked above. I don't believe I have to disable HDMI, but I'll probably do that anyway since this is a headless machine and I could use the extra pins.

As of right now here's what I think I know:
$this->bbcode_list('1')
  • The default device tree blob appears to be /boot/dtbs/am335x-boneblack.dtb
  • The device tree overlay I appear to want is located at /lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
  • In order to load that overlay I need to look at their source (using dtc to decompile) and ensure that neither one is attempting to use resources that the other one wants as well.
  • If the original blob appears to be using resources that the overlay wants then I have to remove it similar to how summers does for HDMI in the aforementioned post.
  • That overlay may be designed to work with kernel 4.14 and may be incompatible with my current kernel (4.18).
  • I need to edit my /boot/boot.txt to remove potential conflicts and load that overlay, which may bork my system. I don't have a UART cable, so if it happens I can rescue from sd card, but with significantly less information than what I may need.

  • It's a little late right now, but I'll try this tomorrow and come back with updates. In the meantime I'd still love guidance.

    Thanks for reading.
    --W
    Wesman26
     
    Posts: 58
    Joined: Mon Feb 06, 2012 2:08 am

    Re: [BBB] Enable PRU on Beaglebone Black

    Postby summers » Sat Oct 20, 2018 1:18 pm

    Yes, my method for enabling the SPI devices, will also work for enabling the PRU interfaces. As the method is mainlined, it should be good going forward - I can't see it ever changing.

    So basically in /boot/boot.txt after the line $this->bbcode_second_pass_code('', ' if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then')
    Insert something like
    $this->bbcode_second_pass_code('', ' fdt addr ${fdt_addr_r}
    load ${devtype} ${devnum}:${bootpart} 0x88060000 /lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
    fdt resize ${filesize}
    fdt apply 0x88060000')
    You may want to try some of the other /lib/firmware/*PRU* files - what the difference is I can't say, I havn't looked into them.

    As regards disabling the HDMI, well first work out if you have to. https://elinux.org/Beagleboard:BeagleBoneBlack iirc is fairly good at showing which pins are needed. One of the best bits of the am335x is that the pin out on the cpu, can be configured between something like 8 different options, but the down side is they can only do one at once - and a few were used for doing the hdmi (which the original beagleboard didn't have ...). Anyway the HDMI can be removed (freeing up the pins), either with the commands I gave, or IIRC by loading /boot/dtbs/am335x-boneblack-bbbmini.dtb. The latter was discovered by someone else, I forget who, but its the simpler method. However does mean you need to override the device tree that uboot detects.

    You asked about the commands used for disabling the hdmi in uboot, they are access the device tree. You can see what your kernel is current running in /proc/device-tree; but better commented is the source: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/am335x-boneblack-common.dtsi and https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/am33xx.dtsi. The numbers are the memory addresses of the various devices.
    summers
     
    Posts: 984
    Joined: Sat Sep 06, 2014 12:56 pm

    Re: [BBB] Enable PRU on Beaglebone Black

    Postby Wesman26 » Sat Oct 20, 2018 5:43 pm

    Thanks, summers! Truly, you are the real MVP.

    I believe that device tree blob to be the one I want, as it seems to target the most recent kernel (4.14 vs 4.4 or 4.10), without a cape, and using rproc instead of UIO. AFAIK UIO has been deprecated since kernel 4.4 in favor of rproc. I'll check it out and update accordingly if I turn out to be wrong.

    Thank you again, for all your guidance, patience, and helpful resources. I'll be back with either more questions in the event my experiment fails, or solutions if I can figure it out.

    --W
    Wesman26
     
    Posts: 58
    Joined: Mon Feb 06, 2012 2:08 am

    Re: [BBB] Enable PRU on Beaglebone Black

    Postby summers » Sun Oct 21, 2018 12:24 pm

    Don't worry to much about the version number of the dtbo file. The device tree is a hardware description of the device, and that is independent of the operating system. So in an ideal world, the device tree would only change when the hardware changes. e.g. you want to use the hardware PRU pins, so need to change the device tree.

    But this doesn't say that the device tree doesn't change, although the standard is fixed (afaik) - how it is used changes, and this may mean the how the device tree is written changes. For example the serdev bus is a new software concept - but it means the device tree changes, to show devices connected to uarts as sub children of the uart ...
    summers
     
    Posts: 984
    Joined: Sat Sep 06, 2014 12:56 pm

    Re: [BBB] Enable PRU on Beaglebone Black

    Postby Wesman26 » Sun Oct 21, 2018 6:02 pm

    Alright, I decided to go with /lib/firmware/AM335X-PRU-RPROC-4-14-TI-PRUCAPE-00A0.dtbo because the one I listed originally didn't seem to enable any pins for the PRU, whereas the cape lists several.

    The pins listed seemed to conflict with some of the ones from HDMI, so I disabled that and loaded the above overlay.

    Upon rebooting I don't see anything different with lsmod, but I did notice uio entries listed. According to this source that doesn't mean that uio is fully enabled, but I worry that leaving them there may prevent me from loading rproc for what I want/need.

    Since I couldn't find a good way to disable uio, I considered using the uio overlay found at /lib/firmware/AM335X-PRU-UIO-00A0.dtbo but the problem is that I can't decompile it. When using dtc I end up with a core dump. I loaded it anyway using the method summers details above and now lsmod shows a uio_pruss module as having been loaded, but I'm not sure that there are any pins associated with the PRUs.

    With the cape, a number of pinmux folders were added to /proc/device-tree/ocp/ for all the pins activated by that overlay, but no such similar structure was added with the UIO alternative.

    For now, I'm going to attempt to follow some instructions from the above link using UIO and see what all I can do. I'll post back with updates asap.
    Wesman26
     
    Posts: 58
    Joined: Mon Feb 06, 2012 2:08 am

    Re: [BBB] Enable PRU on Beaglebone Black

    Postby summers » Sun Oct 21, 2018 6:34 pm

    uio: https://github.com/torvalds/linux/blob/master/drivers/uio/uio.c

    As far as I could see has no handles that the device tree would pick up on. So probably the kernel has no way of knowing it should be loaded. You could try:
    $this->bbcode_second_pass_code('', 'modprobe uio')
    Then see if there is anything useful ...
    summers
     
    Posts: 984
    Joined: Sat Sep 06, 2014 12:56 pm

    Re: [BBB] Enable PRU on Beaglebone Black

    Postby Wesman26 » Tue Oct 23, 2018 9:29 pm

    Alright, so here's where I got.

    lsmod shows modules uio, uio_pdrv_genirq, and uio_pruss all loaded. I was able to get these to show after using the overlay found at /lib/firmware/AM335X-PRU-UIO-00A0.dtbo. I modified some C (note: the commented line changes nothing for me) floating around the net to load a binary to the PRU using libprussdrv and compiled a simple PRU binary using clpru. I was able to get this to run briefly when I executed the host code with privileges (sudo). However, the goal was to get the PRU to set pin P9_25 to high, and that did not occur.

    I realized that the overlay I loaded likely didn't load any pins for the PRU so I took this, which I believe is the source for the overlay on my system, and added pin P9_25 with a pull up resistor like this. Ran mkscr and rebooted to find that my above prussdrv code no longer works. I get a segmentation fault, valgrind shows it occurring in prussdrv_pruintc_init() while trying to access memory address 0xD00 which is not stack'd, malloc'd, or free'd. This is the same error I got previously when trying to run the same code on the other overlay without privileges.

    Here's the bizarre part: if I change back to the previous overlay (without my pins added) I am now getting that same error both with and without privileges. The code simply will no longer run.

    I'm on a deadline, so if I can't get this in the next day or so I'm just going to load an old Debian image with kernel 3.8 and do this the Derek Molloy way.

    I love Arch though, so I'm willing to take whatever suggestions are out there.

    --W
    Wesman26
     
    Posts: 58
    Joined: Mon Feb 06, 2012 2:08 am

    Re: [BBB] Enable PRU on Beaglebone Black

    Postby summers » Wed Oct 24, 2018 8:41 am

    Eeik! next day. Can't see getting a solution on that time scale.

    I may keep pru ticking over in my mind, always meant to get them working on my BBB and PB, but have never had time - and I can't see that improving in near future - alas other priorities ...
    summers
     
    Posts: 984
    Joined: Sat Sep 06, 2014 12:56 pm


    Return to Texas Instruments (TI)

    Who is online

    Users browsing this forum: No registered users and 4 guests