> On Dec 16, 2015, at 7: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..) I believe the problem is in spidev which probably doesn't allocate DMA-coherent memory for the buffer. If you use McSPI and allocate DMA-coherent memory for the buffer it works just fine for > 160 bytes.
Regards, John > > 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.
