Hi! I have an application where I need to have consistent time sampling of some sensors (for instance, sampling every 1ms second) and that it uses little power.
My solution for using little power is to set the processor to sleep every once in a while using rtcwake -d /dev/rtc0 -m mem
However, power management like that only works on kernels from TI.
To have consistent time sampling I decided to use the PRU. I followed the great tutorial from http://exploringbeaglebone.com/chapter13/. However, this depends on uio_pruss which I was only able to get working on Bone kernels. TI kernels use remoteproc_pruss, which I haven’t found any great tutorials on.
I tried installing the uio_pruss module on a TI kernel using https://github.com/izaakschroeder/uio_pruss.
After going through the process, I was even able to load the module. However, it doesn’t work properly. For instance, the folder /sys/class/uio/uio0/maps/ does not even exist on the TI kernels.
Would anyone know how to get uio_pruss working on TI kernel?
If not, would you know another solution that I could try for my application?
Thank you very much!
I was taking a look at chapter 13 yesterday with (v4.1.x-bone), which has
uio_pruss however the uio class doesn't match up 100% either..
So till we have ported that section to v4.1.x it's best to use: 3.8.x for
today..
sudo apt-get update
sudo apt-get install linux-image-3.8.13-bone79
sudo reboot
Regards,
I was taking a look at chapter 13 yesterday with (v4.1.x-bone), which has uio_pruss however the uio class doesn’t match up 100% either…
Robert, what do you mean by this ? I’ve had 4.1.bone working with uio seemingly fine. Which is to say I do not doubt you, just wondering if there is something I’m missing ?
So uio may work fine in 4.1.x-bone, but it's not matching up with the
directions here:
http://exploringbeaglebone.com/chapter13/#The_Programs
Specifically Step 2 "/sys/class/uio/uio0/maps/map1"
I think that's where all the new users are getting confused..
Regards,
debian@beaglebone:~$ uname -r
4.1.20-bone-rt-r20
debian@beaglebone:~$ lsmod | grep uio
uio_pdrv_genirq 3309 0
uio 8311 1 uio_pdrv_genirq
debian@beaglebone:~$ sudo modprobe uio_pruss extram_pool_sz=0x1E8480
debian@beaglebone:~$ lsmod | grep uio
uio_pruss 4582 0
uio_pdrv_genirq 3309 0
uio 8311 2 uio_pruss,uio_pdrv_genirq
debian@beaglebone:~$ cd /sys/class/uio/
debian@beaglebone:/sys/class/uio$ tree
.
0 directories, 0 files
Regards,
Hi Robert and William. Thank you very much for the responses!
I did the following:
root@beaglebone:/sys/class/uio# uname -r
4.1.21-bone-rt-r20
root@beaglebone:/sys/class/uio# lsmod | grep uio
uio_pruss 4582 0
uio_pdrv_genirq 3309 0
uio 8311 2 uio_pruss,uio_pdrv_genirq
root@beaglebone:/sys/class/uio# sudo modprobe uio_pruss extram_pool_sz=0x1E8480
root@beaglebone:/sys/class/uio# ls
uio0 uio1 uio2 uio3 uio4 uio5 uio6 uio7
root@beaglebone:/sys/class/uio# ls uio0/maps/map1
addr name offset size
root@beaglebone:/sys/class/uio# cat uio0/maps/map1/size
0x001e8480
Robert,
Yes, I had noticed, the 8 separate “maps”, and figured that was how it was supposed to be. Despite an older blogpost I was reading aying there was only one pool. Also, I’d have to revisit my notes, but I believe that uio “map” tool does not find the mmap()'d memory either. But, all the examples run fine, and there was another fork on Jason’s git by someone I can not remeber at the moment that demonstrated blinking the USR LEDs through the PRU. It also worked just fine.
So, I do not really know what to think. Except that the uio_pruss userland driver as it sits, seems to function as intended. But there are some oddities such as you pointed out, yes.
Also for what it’s worth, and this is pure speculation( because I have not looked into it fully ) but I do believe map0-map7 all point to the same memory location. It would not be too hard to test to see if my assumption is accurate, but I have not had the time lately for this specifically.
Here it seems like the uio_pruss works for the Bone kernel I used.
But would you have any tips on how I should go with respect to try making uio_pruss work on TI kernels?
Maybe you think it might be possible to sample with consistent 1ms period some other way not using the PRU.
Thank you very much!
Here it seems like the uio_pruss works for the Bone kernel I used.
But would you have any tips on how I should go with respect to try making
uio_pruss work on TI kernels?
So TI's been working on a replacement for "uio_pruss" for awhile called
"remoteproc_pruss", this is what we have enabled in the TI kernel branch..
I've synced most of the ti specific stuff for am335x's so v4.1.x-bone &
v4.1.x-ti are pretty close..
Maybe you think it might be possible to sample with consistent 1ms period
some other way not using the PRU.
Regards,
Pedro,
It would not be too hard to diff the config’ between the two kernel types. As I recall there are two kernel config options that need enabling for uio_pruss to work. However, remoteproc_pruss also has to be diabled, and I’m not sure how thats done. Not to mention at this point I’m not 100% sure all you would have to do it change config options. Maybe there is a patch or something else I’m unaware of.
In other words, it’ too much for me to look into, since I have no interest in this personally. But perhaps you can do some digging and find out yourself ?
It’s more then just the config’s, remoteproc_pruss utilized the same device tree node as uio_pruss, but changed things incompatiblly…
remoteproc_pruss:
https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.1.18-ti-r56/arch/arm/boot/dts/am33xx.dtsi#L854-L899
uio_pruss:
https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.1.21-bone-rt-r20/arch/arm/boot/dts/am33xx.dtsi#L432-L441
Regards,
Ah, right. One thing I did not think of. uio_pruss is an actual UIO driver, where the remoteproc implementation probably is not.