I’m starting to update from an outdated image and to be clean am planning on starting from scratch with a newly flashed image.
On http://beagleboard.org/latest-images there are two possible Debian images from Nov. 12’th, Wheezy 7.9 and Jessie 8.2. It is not clearwhich image I should use. I’m using the PRU and SPI1 (which also previously required SPI0 to be loaded) and many python modules. I load the PRU, SPI0 and SPI1
using three device tree overlays. Could someone recommend which image to use? Thanks and appreciated.
Both will work, however you have to answer this question for yourself. Would you prefer to use systemd, or init as an init daemon ? Debian 8.x is Jessie, and will have newer packages. 7.x is Wheezy, and will have older packages, but also has been “proven”.
What I personally use, and this is not for a production system per se is Wheezy 7.8. Once that image is installed, I then upgrade to a newer 4.1.x kernel, and that’s where I’ve been happy lately. I do a lot of personal testing of various hardware modules, etc, and have found this setup mostly solid.
Do you know if you’re going to use uio_pruss, or remoteproc + rpmsg for the PRU ? The SPI stuff, I’d have to let someone else comment on. No personal hands on yet.
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.
For uio_pruss, use the "4.1.x-bone" kernel vs "4.1.x-ti"..
cd /opt/scripts/tools/
git pull
Then either:
sudo ./update_kernel.sh --bone-kernel --lts
or (for rt)
sudo ./update_kernel.sh --bone-rt-kernel --lts
Regards,
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,
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…)
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 . . .
I didn't investage that side.. It's just when used as an overlay, that's
needed..
If you setup a *.dtb with spi enabled in the dtb-rebuilder you don't need
that workaround..
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-spi0.dts#L140
Regards,
Hmm according to that device tree source, max frequency is 16Mhz. I thought the SPI was capable of 30Mhz or more. Maybe I’m remembering wrongly.
the old 3.8 tree also had 16Mhz..
https://github.com/beagleboard/linux/blob/3.8/firmware/capes/BB-SPIDEV0-00A0.dts#L63
I think i defaulted to that for 4.1.x's overlay and didn't want to chance it..
Regards,
Yes, you can control the SPI with the PRU. Take the SPI driver from Starterware and adapt it to work on the PRU and then build with the PRU C compiler. SPIDEV is a Linux feature and has nothing to do with the PRU. Starterware is barebone programming where you manipulate the peripheral, bus and clock registers directly using the CortexA8 ARM processor. The PRU can manipulate these same registers. From what I remember, there is a github project that has already ported some of the Starterware drivers to work on the PRU.
Regards,
John
Normally SPI’s are good up to 100MHz, but this is seldom needed. I normally set them up at 1MHz for initial debug (allows for cheaper instruments) and then usually go to 10MHz which normally makes speed a non-issue and allows for longer wires. 16MHz should be fine as well. I2C’s often run around 1MHz and are very dependent on length (i.e. capacitance). One needs to keep I2Cs high when not used to minimize power due to pull-ups. SPI’s, once you get them going, are generally a better choice.
Robert, I haven’t used dtb-rebuilder, does one need to recompile the Kernel to use it? Also, in the main dts, it appears only spi0 is enabled, but I use spi1 due to pin conflicts on the BBB cape headers; does dtb-rebuilder support spi1?
Currently I’m fighting with WiFi; I had scripts to detect the wlanx device using iw dev | grep “Interface” | awk ‘{printf $2}’ but this is failing at boot; it works fine after boot. I tried hard coding the wlanx device, but now it seems to change; when I specify wlan0, it comes up as wlan1, and vice versa? It seems wireless networking changed somewhat from my previous version, and I haven’t tracked down what yet. So wireless first, apt-gets second, pips third, device trees fourth, prus fifth, and then tracking down why previously debugged software stopped working. It might be interesting to keep track of how many issues come up.
Anyways, for now, I am going with v4.1.x and will probably do Robert’s suggestions re
Search github for starterware_PRU
Regards,
John
So the "dtb-rebuilder" just rebuilds the dtb files..
But stay with the correct abi...
For "v4.1.x-ti/v4.1.x-rt-ti" kernels, use the "4.1-ti" branch
git clone -b 4.1-ti https://github.com/RobertCNelson/dtb-rebuilder dtb-4.1-ti
For "v4.1.x-bone/v4.1.x-rt-bone" use the 4.1.x branch"
git clone -b 4.1.x https://github.com/RobertCNelson/dtb-rebuilder dtb-4.1.x
By default these will generate the exact same *.dtb's that are
installed by the linux-image-xyz
You can customize them however you want:
to build/install:
make
sudo make install
sudo reboot
Regards,
Currently I'm fighting with WiFi; I had scripts to detect the wlanx device
using iw dev | grep "Interface" | awk '{printf $2}' but this is failing at
boot; it works fine after boot. I tried hard coding the wlanx device, but
now it seems to change; when I specify wlan0, it comes up as wlan1, and vice
versa? It seems wireless networking changed somewhat from my previous
version, and I haven't tracked down what yet. So wireless first, apt-gets
second, pips third, device trees fourth, prus fifth, and then tracking down
why previously debugged software stopped working. It might be interesting to
keep track of how many issues come up.
Sounds like the wifi device has a mac that changes..
Right a udev rule to push it back to wlan0..
here's an example of a udev rule we used on teh bbb's for the eth0:
For example, enp2s0 on my desktop:
$ sudo udevadm info -a /sys/class/net/enp2s0
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:15.0/0000:02:00.0/net/enp2s0':
KERNEL=="enp2s0"
SUBSYSTEM=="net"
DRIVER==""
ATTR{addr_assign_type}=="0"
ATTR{addr_len}=="6"
ATTR{address}=="bc:5f:f4:e5:9d:83"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{carrier}=="1"
ATTR{carrier_changes}=="1"
ATTR{dev_id}=="0x0"
ATTR{dev_port}=="0"
ATTR{dormant}=="0"
ATTR{duplex}=="full"
ATTR{flags}=="0x1003"
ATTR{gro_flush_timeout}=="0"
ATTR{ifalias}==""
ATTR{ifindex}=="2"
ATTR{iflink}=="2"
ATTR{link_mode}=="0"
ATTR{mtu}=="1500"
ATTR{name_assign_type}=="4"
ATTR{netdev_group}=="0"
ATTR{operstate}=="up"
ATTR{speed}=="1000"
ATTR{tx_queue_len}=="1000"
ATTR{type}=="1"
looking at parent device '/devices/pci0000:00/0000:00:15.0/0000:02:00.0':
KERNELS=="0000:02:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="alx"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x020000"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{d3cold_allowed}=="1"
ATTRS{device}=="0x10a1"
ATTRS{dma_mask_bits}=="64"
ATTRS{driver_override}=="(null)"
ATTRS{enable}=="1"
ATTRS{irq}=="38"
ATTRS{local_cpulist}=="0-3"
ATTRS{local_cpus}=="f"
ATTRS{msi_bus}=="1"
ATTRS{numa_node}=="-1"
ATTRS{subsystem_device}=="0x10a1"
ATTRS{subsystem_vendor}=="0x1849"
ATTRS{vendor}=="0x1969"
looking at parent device '/devices/pci0000:00/0000:00:15.0':
KERNELS=="0000:00:15.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060400"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{d3cold_allowed}=="0"
ATTRS{device}=="0x43a0"
ATTRS{dma_mask_bits}=="32"
ATTRS{driver_override}=="(null)"
ATTRS{enable}=="1"
ATTRS{irq}=="24"
ATTRS{local_cpulist}=="0-3"
ATTRS{local_cpus}=="f"
ATTRS{msi_bus}=="1"
ATTRS{numa_node}=="-1"
ATTRS{subsystem_device}=="0x0000"
ATTRS{subsystem_vendor}=="0x1022"
ATTRS{vendor}=="0x1022"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
Regards,
Normally SPI’s are good up to 100MHz, but this is seldom needed. I normally set them up at 1MHz for initial debug (allows for cheaper instruments) and then usually go to 10MHz which normally makes speed a non-issue and allows for longer wires. 16MHz should be fine as well. I2C’s often run around 1MHz and are very dependent on length (i.e. capacitance). One needs to keep I2Cs high when not used to minimize power due to pull-ups. SPI’s, once you get them going, are generally a better choice.
SPI through the PRU seems to be limited at around 21.2Mhz. At least an implementation I was just reading about. It seemed that the author was bit banging however. Using the other PRU core for the clk timer as well.
No need to bitbang unless you want additional SPI ports available. Simply use the McSPI port controlled from the PRU.
Regards,
John
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
driverdebian@beaglebone:~$ lsmod |grep pru
uio_pruss 4143 0
uio 8006 2 uio_pruss,uio_pdrv_genirqI'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:bb.org-overlays/src/arm/BB-SPIDEV0-00A0.dts at master · beagleboard/bb.org-overlays · GitHub
"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