pru + 4.4 kernel?

[Jay Doobie]

Hi, I was hoping to upgrade from 3.8.13 to the 4.4.x kernels and installed 4.4.30 on my BBB, my app fails on the following call:

/* Open PRU Interrupt */
	if ((ret = prussdrv_open(PRU_EVTOUT_0))) {
	printf("prussdrv_open open failed\n");
	return;
	}

 

Any ideas or pointers on upgrading? 

[Greg]

Jay, you have to do a minimal edit to the device tree and rebuild the blobs.

I'm pretty sure 4.4.x kernels will require this (not sure exactly when this was rolled out).

Clone this to your Beaglebone:

https://github.com/RobertCNelson/dtb-rebuilder

Look in the directory src/arm.

Find the file:

am335x-bonegreen.dts

or

am335x-boneblack.dts

In the file, you need to uncomment a line like:

/* #include "am33xx-pruss-uio.dtsi" */

Then you need to create a very simple file

/etc/modprobe.d/pruss-blacklist.conf

and include the following:

 blacklist pruss

 blacklist pruss_intc

 blacklist pru-rproc

You will find instructions for the above in the dts file.

Then

make

make install

reboot

Then see if it works!  Good luck.

Greg

[Jay Doobie]

Sadly this did not work.  I'm using the default kernel/setup from the image bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz.  It uses kernel 4.4.30-ti-r64. Is there something better to start with?  I'd like something newer than the 2012 build I previously had.

[William Hermans]

On Thu, Dec 15, 2016 at 8:40 PM, Jay Doobie <doob...@gmail.com> wrote:

Sadly this did not work.  I'm using the default kernel/setup from the image bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz.  It uses kernel 4.4.30-ti-r64. Is there something better to start with?  I'd like something newer than the 2012 build I previously had.

If that did not work, then you're doing something wrong, or you missed a step. But you can not just do what Greg suggested and have it work. You need to make sure you either replace the exact board file you load at boot, or change the board file that loads at boot.

Anyway, I know what Greg suggest works, because I was the first person on the list to test the changes, on the list. Once Robert posted to the list about these changes. In fact, if you search my username on this google group, with the additional keyword "uio_pruss", it probably won't take you long to find the exact steps post I made.

[Jay Doobie]

I figured out what happened, it wasn't am335x-boneblack.dts, but am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but I don't see it doing what it should be doing.  Need to grab a copy of prudebug and see if I can debug what the PRU is trying to do vs. is doing.

Thanks!

[TJF]

Hello Jay!

You need not adapt the device tree when you use a bone kernel. (The device tree fixup is for TI kernels only.)

Am Freitag, 16. Dezember 2016 05:44:26 UTC+1 schrieb Jay Doobie:

I figured out what happened, it wasn't am335x-boneblack.dts, but am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but I don't see it doing what it should be doing.  Need to grab a copy of prudebug and see if I can debug what the PRU is trying to do vs. is doing.

PRU software is independant from the kernel. Once the driver is loaded accordingly, all should work. (Exept the PWM outputs of the eHRPWM modules in the PWMSS subsystems.)

Regards

[Jay Doobie]

Hi TJF: is there some place I can find more info on the DT's across kernels?  I'm using 4.4.30-ti-r64.  I have access to the PRU, and I think my DT isn't updating anything (even though it seems to install properly).  My DT can be seen here:

https://github.com/doobie42/OpenPegasus/blob/master/dto/openpegasus-00A0.dtsi

Thanks,

Jason

[William Hermans]

Jay,

If by "updating" you mean your overlay isn't loading at boot. That would be because the overlay is not in the initramfs. Which is needed for the latest images. I actually posted on the groups about this a few days go, so I'll find my post and copy paste the procedure here.

If this is not what you mean, post back and describe in more detail what you mean by "updating".

--
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/62ff2009-8a84-49d7-b8e4-b71f2bdd3867%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[William Hermans]

So whatever way that works for you, is the right way. But yes, in my own opinion loading from uEnv.txt is the proper way. As the pin configurations take place the quickest possible after a boot.

1. So you need the overlay in /lib/firmware of course.
2. Then you need to add the overlay to the cape_enable=bone_capemgr.enable_partno= line in uEnv.txt
   
3. Finally you'll need to update the initramfs

To update the initramfs You need to:

william@beaglebone:~$ cd /opt/scripts/
william@beaglebone:/opt/scripts$ git pull /* So you need to sudo apt-get install git - If not already installed */

william@beaglebone:/opt/scripts$ cd tools/developers/

william@beaglebone:/opt/scripts/tools/developers$ sudo ./update_initrd.sh

william@beaglebone:/opt/scripts/tools/developers$ sudo reboot

Then your custom overlay will be "injected" into the initramfs, and properly load at boot.

[Jay Doobie]

I was grepping /sys/kernel/debug/pinctrl/44e10800.pinmux/pins for 994 -B 4 -A4 

and loading my overlay manually: "echo openpegasus > /sys/devices/platform/bone_capemgr/slots"

According to dmesg it seems like it accepts my overlay without error.

I'll keep the above in mind when I try to load it by default on boot.

/Jason

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[William Hermans]

Jay,

Ok, so can you describe in more detail what the problem is ? Also pasting the output of the commands you're running to test your overlay may help too.

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/255d6cdc-7ba5-4d31-9f81-dbb1c96bba9a%40googlegroups.com.

[Jay Doobie]

Ya know, I figured out what happened, I wish things were a bit better documented, what you indicated above about creating the initramfs fixed it.  I believe what happened was I modifed the uEnv.txt file and thought it took my changes, but it didn't.  I was running still with HDMI enabled and that conflicted with my DTS.

I'll have to reassemble the machine now (I took the board out to put on a scope), but the values in the pinmux/pins file look correct now.

/Jason

[William Hermans]

On Fri, Dec 16, 2016 at 11:55 AM, Jay Doobie <doob...@gmail.com> wrote:

Ya know, I figured out what happened, I wish things were a bit better documented, what you indicated above about creating the initramfs fixed it.  I believe what happened was I modifed the uEnv.txt file and thought it took my changes, but it didn't.  I was running still with HDMI enabled and that conflicted with my DTS.

I'll have to reassemble the machine now (I took the board out to put on a scope), but the values in the pinmux/pins file look correct now.

/Jason

Ah, yeah, that'll do it. One thing I always do when working with various things that take many commands to perform, and may easily be forgotten or messed up. Is to create a text file of exact steps I've done to achieve my end goal. Then when it comes to duplicating those steps, it turns into a copy paste session that usually succeeds. Which also gives me an easy way of creating a bash script later if needed. What just happened to you, forgetting ti disable the HDMI pins has happened to me before many times in the past . . .

[Jay Doobie]

Yeah, of course now the PRU died, which I had working before .....time to debug that again :)

[Jay Doobie]

I have no idea what I did, but I'm back to nothing working and have been unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my program), nor am I able to have my DTO configure the pinmux anymore. Is there a way to increase debug levels so I can see what is going on when it tries to load my DTO?

/jason 

[Robert Nelson]

On Fri, Dec 16, 2016 at 9:11 PM, Jay Doobie <doob...@gmail.com> wrote:
> I have no idea what I did, but I'm back to nothing working and have been
> unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my
> program), nor am I able to have my DTO configure the pinmux anymore. Is
> there a way to increase debug levels so I can see what is going on when it
> tries to load my DTO?

there's a handy script under:

/opt/scripts/device/bone/

sudo perl show-pins.pl

Regards,

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

[doobie]

Thanks, that is really sweet looking!  No matter what I do when I load my DTO it doesn't seem to change the pinmux/ctrl values unfortunately.    Everything in dmesg, journalctl acts as if it worked successfully, but I see no change to the pinmux/ctlr.  Is there a kernel (or bone_capemgr) level of debug?

/Jason

[Jay Doobie]

I also just realized, I posted this in the BBB group, not the BBB wireless one.  It is a wireless BBB I just received the other day.

On Friday, December 16, 2016 at 10:52:27 PM UTC-5, Jay Doobie wrote:

Thanks, that is really sweet looking!  No matter what I do when I load my DTO it doesn't seem to change the pinmux/ctrl values unfortunately.    Everything in dmesg, journalctl acts as if it worked successfully, but I see no change to the pinmux/ctlr.  Is there a kernel (or bone_capemgr) level of debug?

/Jason

[William Hermans]

Jay,

So keep this in mind, 99% chance, what you've done, you've somehow screwed up. Don't take this as a negative response please. But more or less a realistic response. I've done "similar" myself. the whole time, I might be thinking . .. "I'm going to let x.y.z have it on the groups . . ." only to find that I totally screwed something up in the process.

Yeah do what I say, and completely 100% document what you do, as you do it. Trust me, if you do not thank me for that, you will at least thank yourself for it.

--
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/CAPXoZv97mhYP9eHUY%3DNrjhn6S4_%2BVwe-o_Pe5_XWU0P4G1SytA%40mail.gmail.com.

[William Hermans]

From my own perspective, it does not matter one single bit. I suscribe to the beagleboard.org google group, i get all mails from that group. No idea of sub groups, or whatever. . . .quite honestly I don;t even care. If i know the answer or can give some clues, I'll answer, or give some clues.  .

--
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/265b9483-7ba4-4ef5-a4bd-20a9cb91d84d%40googlegroups.com.

[Jay Doobie]

I certainly expect I screwed something up.  I've yet to see a website that really does a good job describing how to get the pru enaled or setting a main DT or overlay.  I was going to try to grab the source for my old main DT and see if I am missing something. I have't been able to get either the PRU or pinmux working again since last yesterday and I stayed up way too late trying.  I'm going to give it an hour or two today then I need to get going on other projects.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Greg]

Hi Jay, you are correct it is difficult to work through all the issues and find the right sources of information.

I did attempt to document the current process for activating the PRU with Remoteproc:

https://github.com/Greg-R/pruadc1

More specifically look in the PDF file:

https://github.com/Greg-R/pruadc1/blob/master/doc/PRUADC1latex/PRUADC1.pdf

and go to the chapter 10 which has a list of the process for enabling the PRU with Remoteproc.

Setting up UIO PRUSS should be similar, uncomment a different line and blacklist the Remoteproc modules.

I hope I got this stuff correct, as it is a compilation of stuff I got from this group combined with my own experiments.

My general plan of attack so far is to use Universal IO and the config-pin utility if I can.

If you look at the discussions here, many many of them are asking how to work out issues with the Device Tree.

I try to not touch Device Tree stuff if I don't have to.

Of course, my latest project had to tweak the Device tree with an include file, and it worked.  I lucked out on that one!

I totally agree with William that you have to take notes and make sure you can find them a few months later.

It's easier said than done, but it's worth making the attempt.

[Jay Doobie]

uEnv.txt: https://github.com/doobie42/OpenPegasus/blob/master/uEnv.txt

Some progress that might shed light into issues?

I have modified the dts files from the dts-rebuilder and in one I can access the PRU, and in the other I can get the pins set the way I want, but sadly not at the same time.

PRU works:     https://github.com/doobie42/OpenPegasus/blob/master/dtb-rebuilder/src/arm/am335x-boneblack-wireless-emmc-overlay.dts  

pinmux works: https://github.com/doobie42/OpenPegasus/blob/master/dtb-rebuilder/src/arm/am335x-boneblack-wireless.dts

If it is easier for me to post the decompiled DTS (so it is in a single file) or DTB let me know,

/Jay

On Saturday, December 17, 2016 at 8:40:30 AM UTC-5, Jay Doobie wrote:

[Greg]

Not totally clear what you are saying.  I see you have the UIO PRUSS line uncommented in "PRU works".

It is not uncommented in "pinmux works".

So are you saying when you uncomment the UIO PRUSS line to activate it, it kills the pinmux?

Sorry for the confusion!

[Jay Doobie]

Ahhh! Ok, I had modified things so much last night I went back to the original and forgot to update the uio pruss in the non-overlay version.  It WORKS!

When I was saying pinmux works, I guess I should have indicated that I was trying to set 990, 99c, 994 to 0x15.  

So it appears something in the *overlay version is preventing my pinmux from being set the way I wanted it, but (for now) it works!

Thank you so much everyone!

/Jason

[Greg]

Great news, keep going!  Greg