Hi Joseph,
As I said before, Robert wasn’t able to get Remoteproc working using devicetree overlays, so he provided instructions on how to modify the devicetree and then use dtb-rebuilder to create dtbo file. The default is to have neither Remoteproc nor uio_pruss installed because most users don’t use PRU. Once you have a custom dtbo file created, you can use that with kernels > 4.4-ti. Robert did manage to get the uio_pruss overlay to work, but since the remoteproc overlay had issues, better to stay with the standard method and use the dtb-rebuilder and blacklist method.
Here are Robert’s original instructions:
You can swap between rproc and uio for the pruss…
while, uio can be loaded as an overlay, rproc was failing, so we need
to use the dtb-rebuilder…
Step 1:
upgrade to r34 and reboot:
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#4.4.x-ti
Step 2:
Install dtb-rebuilder:
git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder
dtb-4.4-ti --depth=1
cd ./dtb-4.4-ti/
Step 3: (rproc)
Edit your device tree:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-bonegreen.dts#L16-L22
nano src/arm/am335x-bonegreen.dts
Change:
/* #include “am33xx-pruss-rproc.dtsi” */ → #include “am33xx-pruss-rproc.dtsi”
make ; sudo make install
set blacklist:
cat /etc/modprobe.d/pruss-blacklist.conf
blacklist uio_pruss
and reboot…
Regards,
John
BTW, if you want to use 4.1 kernel, then use 4.1-bone for uio_pruss and 4.1-ti for remoteproc.
Regards,
John
Robert.
You instructions here: https://groups.google.com/forum/#!searchin/beagleboard/Robert$20Nelson$20r34%7Csort:date/beagleboard/l59Dx8ygxNg/GhdRzR7IDAAJ do not work.
I do not what to tell you other than I followed you instructions to the “T” and . . .
william@beaglebone:~$ lsmod |grep uio
uio_pdrv_genirq 3661 0
uio 8776 1 uio_pdrv_genirq
william@beaglebone:~$ uname -r
4.4.14-ti-rt-r34
william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2016-05-01
william@beaglebone:~/dev/dtb-4.4-ti$ grep “#include” src/arm/am335x-boneblack-emmc-overlay.dts
#include “am33xx.dtsi”
#include “am335x-bone-common.dtsi”
#include “am33xx-overlay-edma-fix.dtsi”
/* #include “am33xx-pruss-rproc.dtsi” */
#include “am33xx-pruss-uio.dtsi”
Right, and . . .
william@beaglebone:~/dev/dtb-4.4-ti$ head /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=4.4.14-ti-rt-r34
#uuid=
#dtb=
##BeagleBone Black/Green dtb’s for v4.1.x (BeagleBone White just works…)
##BeagleBone Black: HDMI (Audio/Video) disabled:
dtb=am335x-boneblack-emmc-overlay.dtb
RT kernel strikes again apparently . . .
william@beaglebone:~/dev/dtb-4.4-ti$ sudo apt-get install linux-image-4.4.14-ti-r34
william@beaglebone:~/dev/dtb-4.4-ti$ sudo reboot
william@beaglebone:~$ uname -r
4.4.14-ti-r34
william@beaglebone:~$ cd dev/dtb-4.4-ti/
william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install
william@beaglebone:~/dev/dtb-4.4-ti$ sudo reboot
william@beaglebone:~$ lsmod |grep uio
uio_pruss 4928 0
uio_pdrv_genirq 3539 0
uio 8822 2 uio_pruss,uio_pdrv_genirq
So apparently you got bit by the rt kernel bug as many have in the past. So, if you want to use uio_pruss right now with TI’s most recently kernel. You’re going to have to opt out of using an rt kernel. Which honestly is not a huge deal.
ok thanks William for the heads-up. Did a check on 4.1.5-ti-r10, so the non-rt version, but no luck yet (but not out of options). Had one failure again truing to apt-get install a 4.1.5 bone15 kernel, so need to try that as well. I missed Robert’s remark though earlier in the post to use 4.4.x-ti r34 or later and would like to try that as well.
—> So to clarify, best bet is to use 4.4.x-ti r34, the non-rt version, in order to use uio_pruss?
small progress here;
4.4.x-ti r34 did not result in any good (only remoteproc as far as I could tell), no uio.
Therefore went for the bone version, non -rt:
cd /opt/scripts/tools/
sudo git pull
sudo ./update_kernel.sh --bone-kernel --lts-4_4
which gave me
kernel 4.4.15-bone11
and a new dmesg after loading my dtbo:
[Mon Jul 18 19:44:48 2016] pruss_uio 4a300000.pruss: pins are not configured from the driver
[Mon Jul 18 19:44:49 2016] bone-pinmux-helper ocp:pinctrl_generated_pinmux: could not find pctdev for node /ocp/interrupt-controller@48200000, deferring probe
Probably the pro loader does not work yet because of this, and quits with prussdrv_open() failed
So I think I need to figure out a bit of my device tree to get the correct pinmuxing / overlay file now.
^ looks like you aren't using the dtc compiler for v4.1.x+ targets..
Regards,
Well, not to mention you installed a bone kernel anyhow. So what we’re talking about is really moot. e.g. a topic for a different discussion.
So. . . back on topic . . .
Download suitable linu image and reboot:
william@beaglebone:~$ sudo apt-get install linux-image-4.4.14-ti-r34
william@beaglebone:~$ sudo reboot
Install git and check your dtc version:
william@beaglebone:~$ sudo apt-get install git
william@beaglebone:~$ dtc -v
Version: DTC 1.4.1
Clone the git into a suitable location:
william@beaglebone:~$ cd dev
git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder dtb-4.4-ti --depth=1
william@beaglebone:~/dev$ cd dtb-4.4-ti/
Edit the needed board file( this will be different for every situation )
william@beaglebone:~/dev/dtb-4.4-ti$ nano src/arm/am335x-boneblack-emmc-overlay.dts
change:
/* #include “am33xx-pruss-uio.dtsi” */
to:
#include “am33xx-pruss-uio.dtsi”
Build from source, and install the board file:
william@beaglebone:~/dev/dtb-4.4-ti$ make
william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install
Blacklist the remoteproc drivers:
william@beaglebone:~/dev/dtb-rebuilder$ sudo nano /etc/modprobe.d/pruss-blacklist.conf
blacklist pruss
blacklist pruss_intc
blacklist pru-rproc
william@beaglebone:~/dev$ sudo reboot
Test to see if the device tree file loaded successfully:
william@beaglebone:~$ lsmod |grep uio
uio_pruss 4928 0
uio_pdrv_genirq 3539 0
uio 8822 2 uio_pruss,uio_pdrv_genirq
Finally, that worked William (&John &Robert)! I did a small check with an LED and am able to with it on/off now via the PRU and uio.
For your consideration, I wonder how you feel like to document this more structurally so others can benefit from it? I was offset by some older posts on the forum. Next thing I just though about is to make more use of the .deb functionality instead of relying on script or instructions. For instance uio “conflicts” with remoteproc in reality, but both reside on the same sd-card image. Otherwise, I also understood the PRU’s are not that much used, so maybe it;s not worth the effort to invest in this.
Anyway, thanks again for the help, I’d be glad to inform/post the end result of my project somewhere once my time-critical part of c code as transferred to the PRU.
I think it’s pretty well documented here. However you could always write up an eLinux or whatever wiki page . . . I do have my own web page http://www.embeddedhobbyist.com/ with stuff on it that is important to me. But this information for using UIO on TI kernels I feel is largely useless. Because
The method for enabling either / or will likely change in the future.
Right now, personally I’m still favoring bone kernels, and I know I’m not alone.
This is really a trivial “fix”. Or something that is really easy to remember how to do.
@Robert, any idea on if TI plans on cleaning up the kernel module mess that now “infests” TI kernels ? using something like 50M + memory needlessly . . .
It's... debug_info..
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
CONFIG_DEBUG_INFO_SPLIT=y
CONFIG_DEBUG_INFO_DWARF4=y
"atleast" the zImage isn't bloated, but the modules are 4x/5x bigger...
a few users wanted to use systemtap:
https://wiki.archlinux.org/index.php/SystemTap
that needs debug_info..
Regards,
Sorry Robert I did not mean to reply only directly to you . . . but also . . .
a few users wanted to use systemtap:
https://wiki.archlinux.org/index.php/SystemTap
that needs debug_info…
So question about this. Are these few people more important than the rest of the users out here ? Not meant as a smart ass question seriously. I mean if I have to I can always compile my own kernel, but not everyone has the know how.
My idea of of images and kernels for the beaglebone has always been minimal. Nothing wrong with perhaps compiling with modules in mind, but keeping things standard so people can find out easily how to change these image properly to get where they want to be. But that’s my idea . . .
Ah those! most of them come from loading the cape overlay… (cape_universal=enable)
Regards,
Seriously ? Wow I had no idea. Is this a requirement, or can it be changed ? Or . . .hmmm how could one modify this behavior so that only what’s needed is loaded. Other than my hackish fix. Or, do we need cape_universal=enable to use universal-io ? I honestly have not experimented with disabling cape_universal and temptation to use universal IO.
temptation <— wtf did that come from . . . dahm spell checker lol. attemtping . . .
So the cape_universal=enable, is just to hook to more easily disable/enable
universal-io at bootup.
But yeah, what universal-io does, "everything" inside the chip get's
enabled, except for the pinmux-ing.. Which you control (the pinmuxing) in
userspace..
It's more reliable then loading/unloading individual peripherals, but it
has a different cost (memory and possiblly power)
Regards,
Ok, thanks Robert. I am really starting to warm up to universal-io. Never had the chance, or reason to get it working before. Now . . . I’m using it to test custom cape circuits, and all kind of things.
Plus I really do want to write that webpage GPIO / peripheral configuration page . . . but that may still be a while yet. Still have many other priorities . . . and much if it has nothing to do with computers. Unfortunately.
Hi Robert,
I was one of those users who uses Systemtap, but I always build my own kernel with debug symbols enabled, so I would recommend a standard kernel version without debug symbols and if you are up to it, add another build with a -dbg.deb kernel/modules version. Regarding the other kernel modules such as pwn, spidev, snd*(no audio on base BBB), c-can, etc, why not add these to the blacklist and have users remove those from the blacklist if they want these drivers available?
Regards,
John