>
> *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
> <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..)*


Is it possible to control the SPI hardware through the PRU, and if so,
would that hack still matter Robert ? No idea if spidev is used in such a
case or not . . .


On Wed, Dec 16, 2015 at 8:24 AM, Robert Nelson <[email protected]>
wrote:

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

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