can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Ashwini Bhat]

Hey Guys,
  I need some help in trying to configure my device tree.  The goal is to make it possible to so that I can use PRUs.  I keep getting stuck getting the device trees loaded.  Help would be greatly appreciated.  To start off here is some info about the machine:
debian@beaglebone:/lib/firmware$ uname -a
Linux beaglebone 4.4.43-ti-r84 #1 SMP Fri Jan 20 16:28:53 UTC 2017 armv7l GNU/Linux
debian@beaglebone:/lib/firmware$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 8.6 (jessie)
Release:    8.6
Codename:    jessie

The text below shows you what happens when I try to load the UART1 device tree

debian@beaglebone:/lib/firmware$ sudo sh -c "echo 'BB-UART1' > /sys/devices/platform/bone_capemgr/slots"
sh: echo: I/O error
debian@beaglebone:/lib/firmware$ dmesg | tail
[  780.776674] bone_capemgr bone_capemgr: Using override eeprom data at slot 5
[  780.776706] bone_capemgr bone_capemgr: slot #5: 'Override Board Name,00A0,Override Manuf,PRU-GPIO-EXAMPLE'
[  780.796089] bone_capemgr bone_capemgr: slot #5: PRU-GPIO-EXAMPLE conflict P8.11 (#4:cape-universaln)
[  780.805395] bone_capemgr bone_capemgr: slot #5: Failed verification
[  810.309452] bone_capemgr bone_capemgr: part_number 'BB-UART1', version 'N/A'
[  810.309506] bone_capemgr bone_capemgr: slot #6: override
[  810.315043] bone_capemgr bone_capemgr: Using override eeprom data at slot 6
[  810.315074] bone_capemgr bone_capemgr: slot #6: 'Override Board Name,00A0,Override Manuf,BB-UART1'
[  810.353761] bone_capemgr bone_capemgr: slot #6: BB-UART1 conflict P9.24 (#4:cape-universaln)
[  810.362487] bone_capemgr bone_capemgr: slot #6: Failed verification
 
This is what my slots file looks like:
debian@beaglebone:/lib/firmware$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universaln


I know the pruss is loaded because is see it in lsmod
debian@beaglebone:/lib/firmware$ lsmod | grep pruss
uio_pruss               5504  0
uio                    10524  2 uio_pruss,uio_pdrv_genirq

Since this basic device tree is not working I don't know what to do. I want get to eventually using PRU, but I keep getting stuck on the damn device trees.  I have gone through Derek Molloy's tutorial, I can get that to work on a different, and older beaglebone black.  What I am concerned with is, I am unable to debug what is happening when the device trees stops working.  I don't want to just copy and paste because then I don't understand what is going on. Any help will be greatly appreciated.

[Ashwini Bhat]

Ok here is a an update.  I had to change uEnV.txt file in /boot and that seems to load device tree without any issues and i made changes to the following lines:
##Example v4.1.x
cape_disable=bone_capemgr.disable_partno=cape-universaln
cape_enable=bone_capemgr.enable_partno=uio_pruss_enable,PRU-GPIO-EXAMPLE

while as before those lines did not have anything to the right of the = sign and th lines were commented out.
I am now trying to use the same device tree as used by http://credentiality2.blogspot.com/2015/09/beaglebone-pru-gpio-example.html
Once I boot up with the device tree I can see the new pins that I got from the device tree:
debian@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots

 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1

 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,uio_pruss_enable
 5: P-O-L-   1 Override Board Name,00A0,Override Manuf,PRU-GPIO-EXAMPLE

But when I go to the run the program as he instructed I run into the following error:
debian@beaglebone:~$ sudo ./pru_loader pru_egp_output.bin
prussdrv_open() failed

I don't know what is causing that error now?  Some guidance would be great (I can move this to another location if necessary)
Also I would like to know why I have to place the binary into the uEnv.txt file and just be able to change it on the fly? Is this requirement true of all linux systems?

[Greg]

Hi Ashwini-

It's not clear that you have modified the device tree to activate a PRU driver framework.

Check out this discussion:

https://groups.google.com/forum/#!category-topic/beagleboard/JQ14qQC-Ggw

If you did in fact activate the driver, then please ignore this message.

Please be aware that lsmod may show a driver, however, that doesn't mean that it is active.

Regards,

Greg

[Ashwini Bhat]

I tried your setup, but for some reason after restarting my Ethernet stopped working, and since I wanted to clear the folder and re download the git file, I quickly found out my ethernet is not working...So I have to dig into why that is happening....I am going to try it again once I get the Ethernet working.

[Ashwini Bhat]

I don't know why my ethernet is not working, I think it is caused by the device trees.  Anyways I tried following your setup but I only see 4a300000.pruss and not the other 3.  Here is what I see:

lrwxrwxrwx 1 root root 0 Jan 25 07:52 49900000.tptc -> ../../../devices/platform/ocp/49900000.tptc
lrwxrwxrwx 1 root root 0 Jan 25 07:52 49a00000.tptc -> ../../../devices/platform/ocp/49a00000.tptc
lrwxrwxrwx 1 root root 0 Jan 25 07:52 4a100000.ethernet -> ../../../devices/platform/ocp/4a100000.ethernet
lrwxrwxrwx 1 root root 0 Jan 25 07:52 4a300000.pruss -> ../../../devices/platform/ocp/4a300000.pruss
lrwxrwxrwx 1 root root 0 Jan 25 07:52 4c000000.emif -> ../../../devices/platform/ocp/4c000000.emif
lrwxrwxrwx 1 root root 0 Jan 25 07:52 53100000.sham -> ../../../devices/platform/ocp/53100000.sham

any ideas as to why it would not load all of them? I am not seeing anything in dmesg.

[Greg]

You are using a very new IOT image.  I'm still using one from December 2016.

If I can get a few minutes later today, I'll try that new image here.

I'm not sure what to suggest to try next.

Hopefully you can get your ethernet running again.

Greg

[Greg]

Can you tell me which IOT image you are using?  Which Beaglebone?  Did you update the kernel recently?

Greg

[Ashwini Bhat]

Yea I didn't get a chance to look into why my Ethernet is failing (hoping to look into it today at night).  But I really appreciate your help in all this, because I am at an impasse.  If worse comes to worse I might just have to reinstall the image in order to get the Ethernet to work.  I am hoping your help will provide me a better understanding of device trees and how to use PRUs.  Any ways, I am using the following
settings:

debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.44-bone16 #1 Sat Jan 21 10:38:02 UTC 2017 armv7l GNU/Linux
debian@beaglebone:~$ lsb_release -a

No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 8.6 (jessie)
Release:    8.6
Codename:    jessie

It is a beaglebone black Rev A6.  I am using a 16G SD card and it is booting from SD card I believe.  I am using Debian 8.6 2016-11-06 4GB SD LXQT image from the website.

Let me know if you need more info, and thank you so much again, because this is really helpful.
Thanks,
Ashwini Bhat

[Ashwini Bhat]

Yea I didn't get a chance to look into why my Ethernet is failing (hoping to look into it today at night).  But I really appreciate your help in all this, because I am at an impasse.  If worse comes to worse I might just have to reinstall the image in order to get the Ethernet to work.  I am hoping your help will provide me a better understanding of device trees and how to use PRUs.  Any ways, I am using the following
settings:

debian@beaglebone:~$ uname -a

Linux beaglebone 4.4.44-bone16 #1 Sat Jan 21 10:38:02 UTC 2017 armv7l GNU/Linux
debian@beaglebone:~$ lsb_release -a

No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 8.6 (jessie)
Release:    8.6
Codename:    jessie

It is a beaglebone black Rev A6.  I am using a 16G SD card and it is booting from SD card I believe.  I am using Debian 8.6 2016-11-06 4GB SD LXQT image from the website.

Let me know if you need more info, and thank you so much again, because this is really helpful.
Thanks,
Ashwini Bhat

On Wednesday, January 25, 2017 at 3:57:56 AM UTC-8, Greg wrote:

[Greg]

I have the same hardware available here.  I have not tested the LXQT image, only the IOT and it was with Beaglebone Green.

I'll try to get the image and written to the SD card later today.  It only takes a few minutes for the process including the Device Tree change.

Greg

[Greg]

Can you tell me exactly how you got the kernel 4.4.44-bone16?

I need to replicate this step exactly.

Greg

[Ashwini Bhat]

Damn, I am trying to recall exactly, because at that time I was trying a bunch of things.

I am looking into the history, I am retracing my steps:
I think I updated when I went into /opt/scripts/tools and use ./update_kernel.sh, but I don't believe that updates you to the right version
I don't believe that gets you there, I think you have to do,

sudo ./update_kernel.sh --lts-4_4 --bone-channel

as listed on : https://github.com/beagleboard/bb.org-overlays
 
I think I did ./update_kernel.sh then did ./update_kernel.sh --lts-4_4 --bone-channel, that should get you there. 

Since I am being a bit vague retracing my steps and I am not 100% sure if it can get your 4.4.44-bone16, I can re-image my beaglebone black and then try to retrace my steps or I could try to replicate your setup to see if I can get that to work, since I don't have that much data on this beaglebone black.  Do remember that I have 2gb eMMC since this a older beaglebone so I have to everything off the SD card.  I appreciate your help and I don't want to waste too much of time if this ends up being an abyss of random update, and would rather use your help for something definitive that I can give clear answers too.  Let me know if you are able to get to that version in a short period of time, otherwise I will first try to retrace if that doesn't work then I will go to your version and start from there.
Thanks again,
Ashwini Bhat

[Greg]

I successfully update to the new kernel, it was version 45, not 44 so even a little bit newer.

After updating the DT with the pru include, I rebooted.  No ethernet!

Also, I can tell from the LEDs that something is very wrong.

The heartbeat is there, but one of the other LEDs is blinking steadily and quickly.

I'll get the USB serial and see what is going on.

Meanwhile, if you decide to re-flash the 16G card, then if you simply leave the kernel as it is we can probably make some progress easily enough.

I'm pretty sure the kernel is the same as from the IOT image, and that one I am sure works.

This is a good illustration of why I cringe when any Device Tree stuff has to be touched!

[Ashwini Bhat]

Ok, I am going to try the IOT image, this is the link: http://beagleboard.org/latest-images and I am choosing the one under alternate debian images. 
debian@beaglebone:~$ uname -ar
Linux beaglebone 4.4.36-ti-r72 #1 SMP Wed Dec 7 22:29:53 UTC 2016 armv7l GNU/Linux

debian@beaglebone:~$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 8.6 (jessie)
Release:    8.6
Codename:    jessie

So should I go through your tutorial again see if it works? I have not updated the kernel (is that necessary?)

[Ashwini Bhat]

And yes I agree I really cringe at device trees, they are just so damn hard to debug, I don't know any tools that can help us debug it.

[Greg]

I wouldn't update the kernel at this time.  Yes, try the procedure and see what happens.  I think you will be successful.  If not, we can work through it.

That kernel is the TI version and it should be good to go for sure.  If not, there are problems we are not going to solve without help!

It's still not clear to me the differences between the TI and the Bone kernels.  The TI kernels definitely support the latest Remoteproc.

If you don't need GUI, stick with the IOT image.  I've had very good luck with it.

[Ashwini Bhat]

Ok I did as your procedure says and followed chapter 9. All the outputs you were looking for in your procedure showed up.  Now is there a simple program I can run to see if the PRU is working and if it is able to toggle a GPIO pin?  I can just see if a pin is being toggled by putting a scope on it. 

[Ashwini Bhat]

I tried going past chapter 9 into 10 but now I am getting an error with prumodin.  Ideally I want to know how run a very simple pru set-up that I can debug...but going through what ti has to offer, it all done through code composer.  Doesn't seem like you used it.  Either way I was trying to give yours a shot a and here is where I ended up.
root@beaglebone:/home/debian/pru-software-support-package# ls /usr/bin/ | grep pru
abspru
acpiapru
arpru
asmpru
cgpru
clistpru
clpru
dempru
dispru
embedpru
hexpru
ilkpru
libinfopru
lnkpru
nmpru
ofdpru
optpru
prumodin
prumodout
prumsg
strippru
xrefpru
root@beaglebone:/home/debian/pru-software-support-package# ls /usr/bin/ | grep prumod
prumodin
prumodout
root@beaglebone:/home/debian/pru-software-support-package# ls
examples  labs    Makefile  PRU-Package-v5.0-Manifest.html
include   lib    pru_cape  ReadMe.txt
root@beaglebone:/home/debian/pru-pid-motor/software/pru_firmware# ls
AM335x_PRU.cmd    mapfile1      PRU_PID_0.c      resource_table_empty.h
Makefile    PRU_IO_1.c    PRU_PID_0.obj      result
mapfile0    PRU_IO_1.obj  resource_table_1.h  user_space
root@beaglebone:/home/debian/pru-pid-motor/software/pru_firmware# make clean
make: Nothing to be done for 'clean'.
root@beaglebone:/home/debian/pru-pid-motor/software/pru_firmware# make
clpru -I/usr/share/ti/cgt-pru/includeSupportPackage -I/usr/share/ti/cgt-pru/include -I/usr/share/ti/cgt-pru/lib --hardware_mac=on -O2 -v3 --display_error_number --endian=little PRU_PID_0.c -z -i/usr/share/ti/cgt-pru/lib -i/usr/share/ti/cgt-pru/include -i/usr/share/ti/cgt-pru/includeSupportPackage -i/usr/share/ti/cgt-pru/includeSupportPackage/am335x --reread_libs --stack_size=0x100 --heap_size=0x100 --library=/usr/share/ti/cgt-pru/lib/rpmsg_lib.lib -m=mapfile0 ./AM335x_PRU.cmd -o ./result/am335x-pru0-fw --library=libc.a
<Linking>
clpru -I/usr/share/ti/cgt-pru/includeSupportPackage -I/usr/share/ti/cgt-pru/include -I/usr/share/ti/cgt-pru/lib --hardware_mac=on -O2 -v3 --display_error_number --endian=little PRU_IO_1.c -z -i/usr/share/ti/cgt-pru/lib -i/usr/share/ti/cgt-pru/include -i/usr/share/ti/cgt-pru/includeSupportPackage -i/usr/share/ti/cgt-pru/includeSupportPackage/am335x --reread_libs --stack_size=0x100 --heap_size=0x100 --library=/usr/share/ti/cgt-pru/lib/rpmsg_lib.lib -m=mapfile1 ./AM335x_PRU.cmd -o ./result/am335x-pru1-fw --library=libc.a
<Linking>
gcc ./user_space/prumsg.c -o /usr/bin/prumsg
cd result
cp ./result/am335x-pru0-fw /lib/firmware
cp ./result/am335x-pru1-fw /lib/firmware
root@beaglebone:/home/debian/pru-pid-motor/software/pru_firmware# ls
AM335x_PRU.cmd    mapfile1      PRU_PID_0.c      resource_table_empty.h
Makefile    PRU_IO_1.c    PRU_PID_0.obj      result
mapfile0    PRU_IO_1.obj  resource_table_1.h  user_space
root@beaglebone:/home/debian/pru-pid-motor/software/pru_firmware# prumodin
/usr/bin/prumodin: line 9: echo: write error: No such device
/usr/bin/prumodin: line 10: echo: write error: No such device

Any ideas as to what going on?

[Greg]

I think you are making progress, but I'm having a little trouble following the grep pru.

You should end up with 2 firmwares in /lib/firmware with very specific names:

am335x-pru0-fw

am335x-pru1-fw

Just do

ls /lib/firmware

and see if they are there.

Also:

ls /dev

If you got through the example from the support package, there should be a character device file there:

rpmsg_pru30

If you get the above, that is a very good sign that everything is configured and working.

Note that you will probably have to reboot for the character device to appear after successfully compiling the firmwares and moving them /lib/firmware.

Toggling a GPIO is easy.  You will need to use the __R30 special register variable.
Look in the am335x examples directory of the PRU support package:

PRU_gpioToggle

Yes you are correct I didn't use the CCS.  In the case of the PRUs, simple projects are not creating libraries of code.
And the C code files for the PRUs are no problem for the BeagleBone itself to compile.
If you have used a cross-compiler set-up before, there is a lot of configuration required, and probably debugging of problems.

I did see a note that the CCS no longer requires any sort of license.  I might go back and look at it in the future,

but for now the command line via SSH is more than adequate for what I want to achieve with the PRUs.

Greg

[Ashwini Bhat]

so did an ls on /lib/firmware, I am showing part of the ls, but it should show the 2 files you are interested in (bold and underlined):

root@beaglebone:/lib/firmware# ls -l
-rw-r--r--  1 root root   1102 Dec  9 21:09 ADAFRUIT-SPI0-00A0.dtbo
-rw-r--r--  1 root root   1105 Dec  9 21:09 ADAFRUIT-SPI1-00A0.dtbo
-rw-r--r--  1 root root    867 Dec  9 21:09 ADAFRUIT-UART1-00A0.dtbo
-rw-r--r--  1 root root    867 Dec  9 21:09 ADAFRUIT-UART2-00A0.dtbo
-rw-r--r--  1 root root    867 Dec  9 21:09 ADAFRUIT-UART4-00A0.dtbo
-rw-r--r--  1 root root    867 Dec  9 21:09 ADAFRUIT-UART5-00A0.dtbo
-rw-r--r--  1 root root  36256 Jan 30 04:53 am335x-pru0-fw
-rw-r--r--  1 root root  96272 Jan 30 04:53 am335x-pru1-fw
-rw-r--r--  1 root root   1205 Nov 22 15:28 am33xx_pwm-00A0.dtbo
drwxr-xr-x  2 root root   4096 Dec  9 20:49 ar3k
-rw-r--r--  1 root root 153416 Dec  4 22:43 ar5523.bin

Although when I ls /dev I get rpmsg_pru31 not rpmsg_pru30 (again I don't want to show everything, I am going to show the snippet that you are interested in:
root@beaglebone:/dev# ls -ltr
crw-rw---- 1 root spi     153,   1 Jan 30 04:49 spidev1.0
crw-rw---- 1 root spi     153,   3 Jan 30 04:49 spidev2.0
crw-rw---- 1 root spi     153,   2 Jan 30 04:49 spidev2.1
crw-rw---- 1 root spi     153,   0 Jan 30 04:49 spidev1.1
crw------- 1 root root    245,   0 Jan 30 04:50 rpmsg_pru31
drwxr-xr-x 2 root root        2740 Jan 30 04:50 char
prw-r----- 1 root adm            0 Jan 31 05:31 xconsole
crw-rw-rw- 1 root tty       5,   2 Jan 31 05:36 ptmx

In your pdf you look for rpmsg_pru31 instead of rpmsg_pru30, is there a reason you are looking for that one?

Even after doing that I am still getting the following error:

root@beaglebone:/home/debian/pru-pid-motor/software/pru_firmware# prumodin
/usr/bin/prumodin: line 9: echo: write error: No such device
/usr/bin/prumodin: line 10: echo: write error: No such device

root@beaglebone:/home/debian/pru-pid-motor/software/pru_firmware# ls /usr/bin/prum*
/usr/bin/prumodin  /usr/bin/prumodout  /usr/bin/prumsg

I got through part of your tutorial and I am bit a confused.  Why are you copying the .out file to a different file name and then moving it to /lib/firmware? What does that file do?

By the way, thanks again for all your help, this is really helpful.

[Greg]

There are two examples, one for PRU0 and another for PRU1.  So you will get rpmsg_pru30 for PRU0, and rpmsg_pru31 for the other.

So if you are seeing rpmsg_pru31, this is a major step forward and you have it working!!!

Also note the "c" at the first column of the ls; this indicates a character device.  It's good news.

So I think the scripts prumodin and prumodout must be looking for the wrong file names.  It is probable they are not consistent as kernel changes are rolled out.

So:

ls /sys/bus/platform/devices

Do you see PRU related entries as shown in the set-up documentation?  There are probably small differences which are breaking the scripts.

[Ashwini Bhat]

So I think I have it mostly working, I can see rpmsg_pru31 and rpmsg_pru30 in the /dev folder and I saw that prumodin was already enabled, I had to do prumodout first and then prumodin then the script didn't error out.  I see P9_42 toggle for a second and then the pin stays high.  Is that what is supposed to happen?  If that is what is supposed to happen then great! But I do have some questions about why you did certain things during the installation.  Let me know how far off I am.
Thanks,
Ashwini Bhat

[Greg]

OK, great!

So exactly which firmware are you using?  In my docs, for set-up purposes I suggest the PRUmsg Echo Lab 5.

So this example does not intentionally toggle any GPIO.  The idea is that if you can get this lab to work, the PRU RemoteProc kernel drivers are completely functional.

The final thing to do with this example is to compile the user-space C program and run it.

I think the Makefile handles this, but compiling any C program for user-space is easy:

gcc main.c -o pru_msg_test

or something like that.

Running the user-space test program does a simple exercise of the RemoteProc messaging character devices.

Lab 6 toggles an LED using the PRU and uses the same character device mechanism to control the PRU.

Let me know if you have any more questions.  I think you have gained a lot of capability to experiment with the PRUs.

Greg

[Ashwini Bhat]

Sweet! Thanks a lot man! Let me play with this for a day or 2. I am definitely going to have questions but just need to get my thoughts in order!

[Ashwini Bhat]

I did the Echo Lab 5 and everything seemed to go fine. I ran prumsg and all I saw was a quick squarewave and then the pin would stay high.
Ok, I played with it some more and I am trying to get /home/debian/pru-software-support-package/examples/am335x/PRU_gpioToggle example to work.  And as you guessed I am not seeing anything toggle for P8_11 under PRU0.  I see that P8_11 is on pruout (when doing config-pin P8_11) as is defined by https://www.cs.sfu.ca/CourseCentral/433/bfraser/other/2016-student-howtos/PRU_GPIO_guide.pdf  I am not using P8_27 due to having to load in a new overlay and I don't know if its going to load cape-universala is going to boot of the SD card or not, so I didn't want to risk it.  Anyways, everything goes and I hit no errors.  I copied the out file into am335x-pru0-fw.  So I am confused here.  I don't know where the issue is coming from, why I can't see the GPIO pin being toggled on the scope.  I was also going through your directions and had some questions,
Why include am33xx-pruss-rproc.dtsi? Does this mean I have to include some other files for the
Why did you have blacklist certain files? Do I have to blacklist certain files too?
As I am reading through you previous emails maybe I will give my hand at Lab 6 and see if I can see anything toggle in the meantime.  Let me know your thoughts.  This is really helpful, but there is so much going on I am having a hard time wrapping my head around everything that is happening, I don't know if its just me thats having such a hard time...
Thanks again for you time and your patience.
-Ashwini

[Greg]

The am33xx-pruss-rproc.dtsi file has to included to activate the RemoteProc framework.

I don't have any good links to the details, however, there are two frameworks for working with the PRUs that I know of:

UIO

RemoteProc

UIO is far more mature, and from reading various postings here it seems to have some performance advantages.

There are kernel space drivers, and RemoteProc is an example.

There are user-space drivers, and the UIO framework is an example.

You have to start drilling into operating system details, but don't ask me as I am going up the learning curve on this stuff slowly.

If you do some searching there is tons of material to read.

This is good stuff, but there are thousands of details.

Anyway, since some are using UIO, and some are using RemoteProc, it is left to the user to select the active PRU driver framework.

So that is why you have to edit the dts file and re-compile.

Be cautious when loading overlays.  There is lots of obsolete info out there.  You should edit uEnv.txt in the boot directory to accomplish this.

Don't try to use config-pin or the echo slot method which you will find all over the web.

It might work, or it might not, but it is not worth messing with it.  Just edit uEnv.txt and you will get the job done.

Greg