Recommended Image

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.

But it works when the "spi & spidev" node is in the initial *.dtb, but
not as an overlay. It seems like when loaded as an overlay we aren't
getting the correct dma channel/memory/etc..

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

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.

But it works when the "spi & spidev" node is in the initial *.dtb, but
not as an overlay. It seems like when loaded as an overlay we aren't
getting the correct dma channel/memory/etc..

That doesn’t make sense to me. I know a few months ago I was working on a SPI driver and I had the same issue when my buffer exceeded 160 bytes. When I used a DMA-coherent buffer, my driver worked fine. I was using an overlay to load my driver during testing. My driver did not use SPIDEV.

Regards,
John

No need to bitbang unless you want additional SPI ports available. Simply use the McSPI port controlled from the PRU.

If the module is true hardware SPI, you do not even need a PRU involved. Except perhaps to move the data into LInux through some form of shared memory.

That doesn’t make sense to me. I know a few months ago I was working on a SPI driver and I had the same issue when my buffer exceeded 160 bytes. When I used a DMA-coherent buffer, my driver worked fine. I was using an overlay to load my driver during testing. My driver did not use SPIDEV.

It makes perfect sense. One way it using the hardware through it’s registers directly, while the other way is essentially bit banged master mode only SPI.

John, I haven’t heard of McSPI, but I’m running the SPI from a python program on the Arm side based on some Pyside Qt controllers, I’m using the PRU for a logic analyzer and the logic analyzer pins are not available for the SPI, so this could be the reason. I may also use the PRU IEP timer in the future for some fine timing but I don’t think this is relevant.

No need to bitbang unless you want additional SPI ports available. Simply use the McSPI port controlled from the PRU.

If the module is true hardware SPI, you do not even need a PRU involved. Except perhaps to move the data into LInux through some form of shared memory.

It does if the PRU is controlling a SPI type device that needs real-time control loop. Nothing to do with Linux.

That doesn’t make sense to me. I know a few months ago I was working on a SPI driver and I had the same issue when my buffer exceeded 160 bytes. When I used a DMA-coherent buffer, my driver worked fine. I was using an overlay to load my driver during testing. My driver did not use SPIDEV.

It makes perfect sense. One way it using the hardware through it’s registers directly, while the other way is essentially bit banged master mode only SPI.

Now you have lost me. In my case, I have a kernel module that talks to McSPI directly and that works with devicetree overlay and transfer sizes larger than 160 bytes. In Robert’s case, a user space application uses SPIDEV to transfer data to/from SPI, but it dies if the buffer is larger than 160 bytes and he uses devicetree overlay. If the SPIDEV device is in the initial *.dtb, it works fine for buffers larger than 160 bytes. I don’t know where a bitbang comes into this.

Regards,
John

John, I haven’t heard of McSPI, but I’m running the SPI from a python program on the Arm side based on some Pyside Qt controllers, I’m using the PRU for a logic analyzer and the logic analyzer pins are not available for the SPI, so this could be the reason. I may also use the PRU IEP timer in the future for some fine timing but I don’t think this is relevant.

McSPI (Multichannel Serial Port Interface) is the name TI use to refer to their SPI peripheral. The PRU can access almost all the peripheral devices available on the processor. In addition, the PRU has a dedicated serial port and ethernet port from what I remember. I’m not sure I have seen any PRu code for ethernet.

Regards,
John

Kenneth, Have you looked into Beaglelogic ? https://github.com/abhishek-kakkar/BeagleLogic

William, yes, indeed much of my code is based on some of the approaches of Abhiskek; he did a real nice job, and I borrowed some of his techniques with some changes (I only go up to a maximum of 50MS/s whereas Abhiskek goes up to 100MS/s and I don’t use the new TI assembler or the Pru-C compiler - they looked too complicated for me without having someone around that was knowledgeable about how to use them, and I was up and running on pasm2, also I only support up to 12 bits), but my approach is very similar, especially in timing. My user interface is different as my application is different (primarily intended to hook up to buses going to sensors from my cape). I’ve been trying to get my cape linked to the site, but have not been successful in these attempts (not sure why). Currently, working on a second cape (first one is finished along with two sensor interfaces - well hardware anyways, software is never finished - ) with a LoRa transceiver (which has an SPI interface - the Semtech SX1276) and an RTC; first PCB into debug early Jan. but have two jury rigged BBBs talking now to get software started (have established python on arm is plenty fast enough).

There are still a lot of roblems with the Jessie image. At this moment I’d advice to go for Wheezy.

Yes, I am starting to see that Jessie has issues:

  1. 7+ full 10 hour days (some larger not many smaller) to get wired and wired connections (and/or), with fixed IPs, com miserable at boot and compatible with either 192.168.0.0/24 or 192.168.1.0/24 subnets (subnet unknown at boot); finally successful (but can’t help wining as this is only the very first step on getting the new flash upgrade to work), and a jury-rigged re-invent the wheel solution is guaranteed to be a problem (at least I’m getting better with bash scripting; yech!). Recommendation: we need a network manager not developed for desktops in fixed and known environments, but for headless computers with unknown devices and routers at boot. Also, maybe bashdb should included by default (a suggestion for Robert as if he doesn’t have enough to do yet - any word on the X15? - is there still an FCC issue?)

  2. BBB rev. C with Jessie, with both USB to ubuntu host, and with power to 5V connector (required for wireless dongle) almost always reboots at >sudo shutdown -h now; doesn’t happen without the usb connection.

  3. Sometimes (not often but certainly occasionally) on >sudo reboot, BBB reboots, but no LEDs come on; it has booted up as holding the “power/reset” switch down of 10s does turn off the BBB.

Good news, I can boot the BBB over either wireless (Tl-WN722N or TL-WN821N) or eth0 with both Asus (192.168.1.0/24 and TPLINK (192.168.0.0/24) routers, but the time from reboot to login can be quite large (time varies). This would not have been possible without the usb0 always coming up when it is hot-plugged in - this can sometimes take several minutes but seems to always work - thanks Robert (I assume this was you).
Recommendation: do not use bash scripting unless you really need to; it has many many subtle gotchas, is very non-intuitive, is very complicated with many special ways of doing things that can only be learned using a lot of time and searching on how to do things (i.e. powerful but non-efficient for newbies). For a beginner, every line of code needs to be single stepped through using bashdb, get very familiar with >pr and >ev. Recommendation: I really wish I had started with pyroute2 (hoping to find time to redo). Other recommendations: get things working using > sudo ip (or #ip) before scripting, and get familiar with /sys/class/net.

Item 0: I tried originally with connman, and got nowhere; I then tried with systemctl-networkd; this worked fine for a known environment, but I again I got nowhere with an unknown device and unknown sub-net; I gave up on both and went to custom bash scripts mostly using ip and ping (yech! this re-inventing the wheel should not be needed (and again is pretty well guaranteed to come back and get me in the future); unix was first written almost 45 years ago; if anything networking has deteriorated). I maybe should have installed NetworkManager and run with it, but it’s not easily managed in an unknown environment (i.e. it’s designed to have known devices described in /etc/network/interfaces, I don’t know how to use it with unknown devices and unknown subnet without using DHCP which doesn’t allow for fixed IPs - which I need). Note: without a network manager, you need to enable wpa_supplicant.service.

Item 1: many of my initial problems were due to a route on eth0 being set even when the eth0 cable was not plugged in. This meant wlan0 (or wlan1 depending usually but not necessarily on dongle used), could not be used without an >sudo route flush dev eth0. I now bring up a device, see if it works, and if not, flush everything (for that device) and bring it back down before bringing up the other device. With more time, I will use both wired and wireless, but that’s for later. Currently, if both devices, wireless is used (I may change this).

Item 2: adding an address (perhaps temporary) to a device, such as>sudo ip addr add 192.168.0.174/16 (for example - the important thing is the /16) allows both 192.168.0.1 to be pinged (kind of obvious), but also allows 192.168.1.1 to be pinged (this was not obvious to me, which allows one to determine which subnet the BBB is on). After determining the subnet, I go back to /24 addressing.

Item 3: after bringing up a device, the time needed before successful pinging varies. Currently, I bring up a device, wait 3 seconds, try a ping, look at results, and if unsuccessful, try again up to 5 times, it usually works on iteration #2 (sometimes on #1 but not often), I’ve only seen 3 iterations require once (well maybe twice - but after 7+ 10 hour days blindly attempted hundreds of different things, my memory and attention get hazy); I’m guessing this is very environment dependent.

Question: is there something out there I am not aware of that wouldn’t have taken so much time? Maybe I shouldn’t ask this question as a Yes answer will make me look pretty foolish; at least I can now read bash code, for example:
dev=$2
: ${dev:=eth0}
and the difference between ((…)) and $(…) and ${…} (not to mention ...) (and finally needing spaces and ‘;’ in if [ condition ]; then) and why both fi and done are required, and (finally, finally, why “${var1}” is different from ${var1} - looks after null case); again yech! what a convoluted language (it could be worse, I might have had to use perl or even worse apl?)

Summary: I think I’ve gotten bashophobia; if only we could get a true binary compiler for python?.
p.s. anyone used trepan2 with Jessie?

All those problems you have are with the newer kernel..

Feel free to downgrade to 3.8.x

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh --bone-channel --stable

Regards,

Dude, what are you yammering on about ?

Yes, I am starting to see that Jessie has issues:

1) 7+ full 10 hour days (some larger not many smaller) to get wired and
wired connections (and/or), with fixed IPs, com miserable at boot and
compatible with either 192.168.0.0/24 or 192.168.1.0/24 subnets (subnet
unknown at boot); finally successful (but can't help wining as this is only
the very first step on getting the new flash upgrade to work), and a
jury-rigged re-invent the wheel solution is guaranteed to be a problem (at
least I'm getting better with bash scripting; yech!). Recommendation: we
need a network manager not developed for desktops in fixed and known
environments, but for headless computers with unknown devices and routers at
boot. Also, maybe bashdb should included by default (a suggestion for Robert
as if he doesn't have enough to do yet - any word on the X15? - is there
still an FCC issue?)

2) BBB rev. C with Jessie, with both USB to ubuntu host, and with power to
5V connector (required for wireless dongle) almost always reboots at >sudo
shutdown -h now; doesn't happen without the usb connection.

use:
sudo systemctl poweroff

3) Sometimes (not often but certainly occasionally) on >sudo reboot, BBB
reboots, but no LEDs come on; it has booted up as holding the "power/reset"
switch down of 10s does turn off the BBB.

Good news, I can boot the BBB over either wireless (Tl-WN722N or TL-WN821N)
or eth0 with both Asus (192.168.1.0/24 and TPLINK (192.168.0.0/24) routers,
but the time from reboot to login can be quite large (time varies). This
would not have been possible without the usb0 always coming up when it is
hot-plugged in - this can sometimes take several minutes but seems to always
work - thanks Robert (I assume this was you).
Recommendation: do not use bash scripting unless you really need to; it has
many many subtle gotchas, is very non-intuitive, is very complicated with
many special ways of doing things that can only be learned using a lot of
time and searching on how to do things (i.e. powerful but non-efficient for
newbies). For a beginner, every line of code needs to be single stepped
through using bashdb, get very familiar with >pr and >ev. Recommendation: I
really wish I had started with pyroute2 (hoping to find time to redo). Other
recommendations: get things working using > sudo ip (or #ip) before
scripting, and get familiar with /sys/class/net.

Item 0: I tried originally with connman, and got nowhere; I then tried with
systemctl-networkd; this worked fine for a known environment, but I again I
got nowhere with an unknown device and unknown sub-net; I gave up on both
and went to custom bash scripts mostly using ip and ping (yech! this
re-inventing the wheel should not be needed (and again is pretty well
guaranteed to come back and get me in the future); unix was first written
almost 45 years ago; if anything networking has deteriorated). I maybe
should have installed NetworkManager and run with it, but it's not easily
managed in an unknown environment (i.e. it's designed to have known devices
described in /etc/network/interfaces, I don't know how to use it with
unknown devices and unknown subnet without using DHCP which doesn't allow
for fixed IPs - which I need). Note: without a network manager, you need to
enable wpa_supplicant.service.

Item 1: many of my initial problems were due to a route on eth0 being set
even when the eth0 cable was not plugged in. This meant wlan0 (or wlan1
depending usually but not necessarily on dongle used), could not be used
without an >sudo route flush dev eth0. I now bring up a device, see if it
works, and if not, flush everything (for that device) and bring it back down
before bringing up the other device. With more time, I will use both wired
and wireless, but that's for later. Currently, if both devices, wireless is
used (I may change this).

Item 2: adding an address (perhaps temporary) to a device, such as>sudo ip
addr add 192.168.0.174/16 (for example - the important thing is the /16)
allows both 192.168.0.1 to be pinged (kind of obvious), but also allows
192.168.1.1 to be pinged (this was not obvious to me, which allows one to
determine which subnet the BBB is on). After determining the subnet, I go
back to /24 addressing.

Item 3: after bringing up a device, the time needed before successful
pinging varies. Currently, I bring up a device, wait 3 seconds, try a ping,
look at results, and if unsuccessful, try again up to 5 times, it usually
works on iteration #2 (sometimes on #1 but not often), I've only seen 3
iterations require once (well maybe twice - but after 7+ 10 hour days
blindly attempted hundreds of different things, my memory and attention get
hazy); I'm guessing this is very environment dependent.

Question: is there something out there I am not aware of that wouldn't have
taken so much time? Maybe I shouldn't ask this question as a Yes answer will
make me look pretty foolish; at least I can now read bash code, for
example:
dev=$2
: ${dev:=eth0}
and the difference between ((...)) and $(...) and ${...} (not to mention
`...`) (and finally needing spaces and ';' in if [ condition ]; then) and
why both fi and done are required, and (finally, finally, why "${var1}" is
different from ${var1} - looks after null case); again yech! what a
convoluted language (it could be worse, I might have had to use perl or even
worse apl?)

Summary: I think I've gotten bashophobia; if only we could get a true binary
compiler for python?.
p.s. anyone used trepan2 with Jessie?

Regards,

Mostly, problems getting networking operational in Jessie

IMHO, DHCP has no issues with a fixed IP. Either you define the IP in /etc/networks or (if the DNS is under your control) you can define a fixed IP for the MAC-address in question.

Thanks Robert; do you also recommend using sudo systemctl reboot over sudo reboot?

Thanks Robert; do you also recommend using sudo systemctl reboot over sudo reboot?

I think sudo reboot is fine… But one of my bbb’s in my test farm, (7 boards running 24/7 uptime testing with different kernel branches) needs a little per nudge to properly reboot. I wonder if systemctl works better…

I’ve been using >sudo systemctl reboot for the last two days to reboot to see if it would make a difference. Twice I’ve seen after the reboot no LEDs coming on (out of maybe 20 reboots); when this happens, I hold the reset button for 10 seconds to bring down, and then click it again to reboot. Answer: doesn’t work better.

Robert, do you have a link discussing pros/cons of which kernel to use; for example, what does "rt" give? Also, x-ti vs x?

Kennel, google PREEMPT RT if you want to know what rt is. You’ll find plenty of information on the subject. In short though, the RT kernel is a lower latency kernel. Meaning processes should “hog” CPU time less.

As far as the 4.x kernel in General, for the most part it is fine, but there are a few things that do not seem to work correctly. But that is why the kernel is testing. You test it for your purpose, and if something doesn’t work you report it to Robert, and perhaps the issue then get fixed very quickly.

I can tell you that at least for me the 4.x kernel is noticeably more responsive than older kernels.