On Wed, Dec 16, 2015 at 9:20 AM, William Hermans <[email protected]> wrote:
>> I use uio_pruss; I am not at all familiar with remoteproc + rpmsg for the
>> pru (have never even seen any doc on it). I strongly prefer systemd to init.
>> My largest concern is the device trees overlays (for uio_pruss and pinmux);
>> if they work, then I think I can get SPIs going. I just got a BBB running on
>> 8.2 (had a problem with the leds going out rather than all on when flashing
>> finished). Am able to talk through USB. Can't run scite yet; probably need
>> to work on x-windows.
>
>
> Then, Jessie, or Wheezy will work. Jessie having the newer package repo
> advantage.
>
> Enabling uio_pruss is really simple:
>
> /dts-v1/;
> /plugin/;
>
> / {
>     compatible = "ti,beaglebone", "ti,beaglebone-black";
>
>     /* identification */
>     part-number = "pruss_enable";
>     version = "00A0";
>
>      fragment@0 {
>              target = <&pruss>;
>            __overlay__ {
>                       status = "okay";
>
>                    };
>         };
>
> };
>
> debian@beaglebone:~$ dtc -O dtb -o pru_enable-00A0.dtbo -b 0 -@
> pru_enable-00A0.dts
> debian@beaglebone:~$ sudo cp pru_enable-00A0.dtbo /lib/firmware/
> debian@beaglebone:~$ sudo sh -c "echo 'pru_enable' >
> /sys/devices/platform/bone_capemgr/slots"
> debian@beaglebone:~$ dmesg | grep pru
> [ 3699.525797] bone_capemgr bone_capemgr: part_number 'pru_enable', version
> 'N/A'
> [ 3699.545863] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,pru_enable'
> [ 3699.557512] bone_capemgr bone_capemgr: slot #4: dtbo
> 'pru_enable-00A0.dtbo' loaded; overlay id #0
> [ 3699.579751] pruss_uio 4a300000.pruss: pins are not configured from the
> driver
>
> debian@beaglebone:~$ lsmod |grep pru
> uio_pruss               4143  0
> uio                     8006  2 uio_pruss,uio_pdrv_genirq
>
> I'd also recommend upgrading to a 4.1.x kernel as well( if you haven't
> already ). It works great with uio_pruss, but no personal hands on with SPI
> just yet. I've been considering testing, and blogging on my findings.
> Problem is, I'm not exactly an EE, and connecting SPI between embedded
> platforms is not exactly a direct connect situation( LIke UART ). Which is
> exactly how I'd test. Using an MSP430 Launchpad, or an LM4F120 launchpad as
> a slave device.

SPI works great on v4.1.x now, just pay attention this this little
spi-dma-disable hack:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts#L54

"ti,pio-mode;"

Otherwise, the spidev interface will lock up on the 160'th bit...

(3.8 never used dma on spi, so this isn't a regression in speed..)

Regards,

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

-- 
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