Recommended Image

[Bit Pusher]

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 clear

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

[William Hermans]

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

--
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 beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

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.

[Kenneth Martin]

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.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/tdt1TTix7aE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Robert Nelson]

On Tue, Dec 15, 2015 at 9:10 PM, Kenneth Martin <mar...@granitesemi.com> 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.

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,


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

[William Hermans]

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.

[Robert Nelson]

On Wed, Dec 16, 2015 at 9:20 AM, William Hermans <yyr...@gmail.com> 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.
>
>

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

[William Hermans]

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

[Robert Nelson]

On Wed, Dec 16, 2015 at 9:31 AM, William Hermans <yyr...@gmail.com> wrote:

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,

[William Hermans]

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.

--

[Robert Nelson]

On Wed, Dec 16, 2015 at 9:45 AM, William Hermans <yyr...@gmail.com> wrote:
> 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..

[John Syne]

On Dec 16, 2015, at 7:41 AM, Robert Nelson <robert...@gmail.com> wrote:

On Wed, Dec 16, 2015 at 9:31 AM, William Hermans <yyr...@gmail.com> wrote:

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

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

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,

--

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

[John Syne]

On Dec 16, 2015, at 10:13 AM, John Syne <john...@gmail.com> wrote:

On Dec 16, 2015, at 7:41 AM, Robert Nelson <robert...@gmail.com> wrote:

On Wed, Dec 16, 2015 at 9:31 AM, William Hermans <yyr...@gmail.com> wrote:

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

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.

Search github for starterware_PRU

Regards,

John

[Kenneth Martin]

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

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/tdt1TTix7aE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Kenneth Martin
Granite SemiCom Inc.
555 Richmond St. W, BX1200/Suite 905
Toronto ON
416 640-2626, www.granitesemi.com

[Kenneth Martin]

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.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/tdt1TTix7aE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Wed, Dec 16, 2015 at 1:08 PM, Kenneth Martin <mar...@granitesemi.com> wrote:
> 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?

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

[Robert Nelson]

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

https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Networking:UsingasharedSDcardwithMultipleBeagleBone

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

[William Hermans]

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.

--
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 beagleboard...@googlegroups.com.

[John Syne]

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

Regards,

John

[John Syne]

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

[Robert Nelson]

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

[John Syne]

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

>
> Regards,
>
>
> --
> Robert Nelson
> https://rcn-ee.com/
>

[William Hermans]

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

On Dec 16, 2015, at 3:07 PM, William Hermans <yyr...@gmail.com> wrote:

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

[Kenneth Martin]

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.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/tdt1TTix7aE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[John Syne]

On Dec 16, 2015, at 3:13 PM, Kenneth Martin <mar...@granitesemi.com> wrote:

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

[William Hermans]

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

[Kenneth Martin]

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 http://elinux.org/Beagleboard:BeagleBone_Capes 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).

[Maurice H.]

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

[Robert Nelson]

On Sat, Dec 19, 2015 at 2:50 AM, Maurice H. <maus...@gmail.com> wrote:
> There are still a lot of roblems with the Jessie image. At this moment I'd
> advice to go for Wheezy.

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

[Kenneth Martin]

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?

--

[William Hermans]

Dude, what are you yammering on about ?

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 beagleboard...@googlegroups.com.

[Robert Nelson]

On Sat, Dec 19, 2015 at 10:58 AM, Kenneth Martin <mar...@granitesemi.com> wrote:
> 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

[Maurice H.]

On Saturday, 19 December 2015 19:53:18 UTC+1, Kenneth Martin wrote:

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

[blabla...] 

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.

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.

[Kenneth Martin]

Mostly, problems getting networking operational in Jessie

[Kenneth Martin]

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

On 15-12-19 02:18 PM, Robert Nelson wrote:
> use:
> sudo systemctl poweroff

[Robert Nelson]

On Dec 20, 2015 12:56 PM, "Kenneth Martin" <mar...@granitesemi.com> wrote:
>
> 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..

>
> On 15-12-19 02:18 PM, Robert Nelson wrote:
>>
>> use:
>> sudo systemctl poweroff
>
>

> --
> 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 beagleboard...@googlegroups.com.

[Kenneth Martin]

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.

[Kenneth Martin]

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?

[William Hermans]

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.

--

[William Hermans]

Err, Kenneth . . . not kennel . . . ^^