I’m trying to migrate to 4.1 from 3.8, and it seems as if the PRU is up and running on the latest 4.1 kernel. However, a difference is the I’m not getting the 8 uioX (x=0-8) entries in the /dev directory, and therefore the prussdrv library errors out when it can’t find those files.
The prussdrv is looking for this:
The dmesg output on 4.1.13-ti-r33 reports that it is skipping intr mapping…
[ 20.830764] pru-rproc 4a334000.pru0: version 0 event_chnl_map_size 1 event_chnl_map 0000039c [ 20.830799] pru-rproc 4a334000.pru0: sysevt-to-ch[60] → 0 [ 20.830812] pru-rproc 4a334000.pru0: chnl-to-host[0] → 0 [ 20.830823] pru-rproc 4a334000.pru0: skip intr mapping for chnl 1 [ 20.830833] pru-rproc 4a334000.pru0: skip intr mapping for chnl 2 [ 20.830844] pru-rproc 4a334000.pru0: skip intr mapping for chnl 3 [ 20.830854] pru-rproc 4a334000.pru0: skip intr mapping for chnl 4 [ 20.830864] pru-rproc 4a334000.pru0: skip intr mapping for chnl 5 [ 20.830875] pru-rproc 4a334000.pru0: skip intr mapping for chnl 6 [ 20.830885] pru-rproc 4a334000.pru0: skip intr mapping for chnl 7 [ 20.830896] pru-rproc 4a334000.pru0: skip intr mapping for chnl 8 [ 20.830906] pru-rproc 4a334000.pru0: skip intr mapping for chnl 9
Does anyone know how to not skip that? Or a way for me to map them manually?
Thanks,
The TI kernels have remoteproc enabled in the kernel, which will interfere with uio_pruss. You need to switch to a bone kernel.
The kernel I’m using by the way . . .
$ uname -a#1 Thu Oct 1 06:19:41 UTC 2015 armv7l GNU/Linux
$ ls /dev/ |grep uio
$ ./lsuio
hmmm, i don’t see that on 4.1.13-bone16. Maybe I need to use 4.1.13-bone-rt-r16? What is the difference between the bone and bone-rt?
bone-rt has real time enhancements. I do not know all the differences, but the kernel latency seems to be reduced.
Anyway, you do not see what ?
By the way, I had to make my own device tree overlay for the PRU. It’s pretty simple. . . .
/dts-v1/;
/ {
/* identification */
fragment@0 {overlay {
};
};
$ dtc -O dtb -o pru_enable-00A0.dtbo -b 0 -@ pru_enable-00A0.dts#6: ‘Override Board Name,00A0,Override Manuf,pru_enable’#6: dtbo ‘pru_enable-00A0.dtbo’ loaded; overlay id #0
William,
I installed the 4.1.13-bone-rt-r16 kernel, and the /dev/uioX entires showed up. I guess I’ll try using this one. Thanks for the help!
Erik
Micka
November 23, 2015, 4:41pm
8
Hi, did you managed to make this kernel working with the PRU ? Because I got that :
https://www.mail-archive.com/beagleboard@googlegroups.com/msg32826.html
Micka,
Micka,
TI 4.x kernels will not work with “traditional” PRU stuff. TI kernels have remoteproc enabled. . . which takes over the PRU in a different way.
Micka
November 23, 2015, 8:08pm
10
Thx but I just tried to activate the pru in the device tree with:
William,
Have you seen this… when I enable the PRU with a device tree overlay, I get this if I type top : (something to do with the interrupts taking up tons of CPU)
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
Then after a couple minutes, those processes disappear and this appears in /var/log/syslog
Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [679] /devices/platform/ocp/4a300000.pruss/uio/uio0 timeout; kill ithttp://www.rsyslog.com/e/2007 ]http://www.rsyslog.com/e/2007 ]http://www.rsyslog.com/e/2007 ]
What’s odd is my program continues to operate normally, and is using both PRU0 and PRU1 interrupts…
Erik
William,
Have you seen this… when I enable the PRU with a device tree overlay, I get this if I type top : (something to do with the interrupts taking up tons of CPU)
No I haven’t, since I have not been looking. Perhaps the interrupts can be disabled ? I’ll have to look into it, but I do not really have any code / binaries built to use both PRUs. What are you doing exactly ?
Just tell me in high level terms what your program loop does.
You’re not firing an interrupt every program loop are you ?
Those systemd-udevd entries appear as soon as the pru is enabled with the device tree overlay… totally independant of my program that later utilizes the PRU.
Erik
Which file system are you using ? Whats the output of . . .
$ cat /etc/dogtagBeagleBoard.org Debian Image 2015-03-01
So keep this in mind. My base debian rootsfs is Wheezy 7.8. I also disable systemd through uEnv.txt. So I use SYSV versus systemd as an init daemon.
I’m not 100% sure if the above mentioned items can play a role on your error messages. It is simply a guess. I would not think the kernel / kernel modules should be a problem here. But I suppose they could be. However, with that said.
$ cat /var/log/sysloghttp://www.rsyslog.com ”] rsyslogd was HUPed
So, can you give me an order of things you’ve done in order to get you error messages, and I’ll try to duplicate them. Short of installing more stuff on my rootfs, which is already large enough as it is . . .
Ok, I just realized what you said in your last post about systemd messages. So, from here, I’ll assume this has to be related to systemd. heh I completely missed that . . .