By the way, I had to make my own device tree overlay for the PRU. It's
pretty simple. . . .

/dts-v1/;
/plugin/;

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    /* identification */
    part-number = "pru_enable";
    version = "00A0";

     fragment@0 {
             target = <&pruss>;
           __overlay__ {
                      status = "okay";

                   };
        };

};

$ dtc -O dtb -o pru_enable-00A0.dtbo -b 0 -@ pru_enable-00A0.dts
$ sudo cp pru_enable-00A0.dtbo /lib/firmware/
$ sudo sh -c "echo 'pru_enable' > /sys/devices/platform/bone_capemgr/slots"
$ dmesg | grep pru_enable
[  886.921624] bone_capemgr bone_capemgr: part_number 'pru_enable', version
'N/A'
[  886.941686] bone_capemgr bone_capemgr: slot #6: 'Override Board
Name,00A0,Override Manuf,pru_enable'
[  886.981959] bone_capemgr bone_capemgr: slot #6: dtbo
'pru_enable-00A0.dtbo' loaded; overlay id #0


On Sat, Nov 21, 2015 at 10:36 PM, William Hermans <[email protected]> wrote:

> 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 ?
>
> On Sat, Nov 21, 2015 at 7:08 PM, Erik Stauber <[email protected]>
> wrote:
>
>> 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?
>>
>>
>>
>> On Friday, November 20, 2015 at 2:26:38 PM UTC-8, William Hermans wrote:
>>
>>> The kernel I'm using by the way . . .
>>>
>>> $ uname -a
>>> Linux beaglebone 4.1.9-bone-rt-r16 #1 Thu Oct 1 06:19:41 UTC 2015 armv7l
>>> GNU/Linux
>>>
>>> $ ls /dev/ |grep uio
>>> uio
>>> uio0
>>> uio1
>>> uio2
>>> uio3
>>> uio4
>>> uio5
>>> uio6
>>> uio7
>>>
>>> $ ./lsuio
>>> uio7: name=pruss_evt7, version=1.0, events=0
>>>         map[0]: addr=0x4A300000, size=524288
>>>         map[1]: addr=0x9E880000, size=262144
>>> uio6: name=pruss_evt6, version=1.0, events=0
>>>         map[0]: addr=0x4A300000, size=524288
>>>         map[1]: addr=0x9E880000, size=262144
>>> uio5: name=pruss_evt5, version=1.0, events=0
>>>         map[0]: addr=0x4A300000, size=524288
>>>         map[1]: addr=0x9E880000, size=262144
>>> uio4: name=pruss_evt4, version=1.0, events=0
>>>         map[0]: addr=0x4A300000, size=524288
>>>         map[1]: addr=0x9E880000, size=262144
>>> uio3: name=pruss_evt3, version=1.0, events=0
>>>         map[0]: addr=0x4A300000, size=524288
>>>         map[1]: addr=0x9E880000, size=262144
>>> uio2: name=pruss_evt2, version=1.0, events=0
>>>         map[0]: addr=0x4A300000, size=524288
>>>         map[1]: addr=0x9E880000, size=262144
>>> uio1: name=pruss_evt1, version=1.0, events=0
>>>         map[0]: addr=0x4A300000, size=524288
>>>         map[1]: addr=0x9E880000, size=262144
>>> uio0: name=pruss_evt0, version=1.0, events=0
>>>         map[0]: addr=0x4A300000, size=524288
>>>         map[1]: addr=0x9E880000, size=262144
>>>
>>>
>>> On Fri, Nov 20, 2015 at 2:59 PM, William Hermans <[email protected]>
>>> wrote:
>>>
>>>> The TI kernels have remoteproc enabled in the kernel, which will
>>>> interfere with uio_pruss. You need to switch to a *bone* kernel.
>>>>
>>>> On Fri, Nov 20, 2015 at 9:59 AM, Erik Stauber <[email protected]>
>>>> wrote:
>>>>
>>>>> 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:
>>>>> sprintf(name, "/dev/uio%d", host_interrupt);
>>>>>
>>>>> 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,
>>>>> Erik
>>>>>
>>>>>
>>>>> --
>>>>> 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 [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>> --
>> 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 [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to