Re: [beagleboard] Re: PRU Development

I take that back. The last thing I saw I thought was cool was this: https://github.com/boxysean/beaglebone-DMX But also done in 2013 it seems. Matt R also had a github project working with ws28xx serial type LEDs. But it's probably very similar to boxysean's DMX project. Just a different serial

Re: [beagleboard] Re: PRU Development

Back on topic. I wonder if it wouldn't be simpler, and easier for everyone if someone where to just write / create a setup script for both options. It's been a while, so I do not recall the finer details with each process. But I can say while I do not know everything, I'm also not a novice Linux

Re: [beagleboard] Re: PRU Development

On Wed, Mar 1, 2017 at 10:19 PM, Robert Nelson < robertcnel...@beagleboard.org> wrote: > The above is disabled by default as of 2-3 weeks ago.. > I'm still kind of on the fence. I can completely understand wanting to just type ssh root@beaglebone and *bam* be right where I need to be to start

Re: [beagleboard] Re: PRU Development

On Mar 1, 2017 9:36 PM, "William Hermans" wrote: By the way, leaving root enabled via port 22 with no passwd, is an extremely bad idea. So may while those people will whine to no end about that "problem". Perhaps they should be made to understand the implications of leaving

Re: [beagleboard] why is pinmux-helper needed?

This may be a rudimentary linux/dt question, but doesn't the pinctrl-single driver already support this? Couldn't one change the pin configuration by loading a dtc overlay? On Wednesday, March 1, 2017 at 12:26:56 PM UTC-8, john3909 wrote: > > You need to understand how the pins are configured

Re: [beagleboard] Re: PRU Development

By the way, leaving root enabled via port 22 with no passwd, is an extremely bad idea. So may while those people will whine to no end about that "problem". Perhaps they should be made to understand the implications of leaving port 22 wide open to root access ? On Wed, Mar 1, 2017 at 8:27 PM,

Re: [beagleboard] Re: PRU Development

On Wed, Mar 1, 2017 at 7:53 PM, Jason Kridner wrote: > > Let's see who screams. > > Probably the same people as disabling root ssh access. ;-) > That's actually kind of funny. Funny in that recently I noticed that when rebooting one of the later 2016 image from ssh.

[beagleboard] Re: BBBW answer at last Meetup

Jason Before I received your last email I went to Beagleboard.org and then to http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots and grabbed 2017-02-12 SD card image and burned an SD card with it. When I booted it the Access point at 192.168.8.1 was there and

Re: [beagleboard] Re: PRU Development

On Wed, Mar 1, 2017 at 9:39 PM Robert Nelson wrote: > On Wed, Mar 1, 2017 at 8:13 PM, Jason Kridner wrote: > > > > > > On Wed, Mar 1, 2017 at 8:53 PM William Hermans > wrote: > >> > >> Jason, > >> > >> Is this a pure uEnv.txt edit

Re: [beagleboard] Re: PRU Development

On Wed, Mar 1, 2017 at 8:13 PM, Jason Kridner wrote: > > > On Wed, Mar 1, 2017 at 8:53 PM William Hermans wrote: >> >> Jason, >> >> Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify >> the the board overlay file. Or maybe it was one

Re: [beagleboard] Re: PRU Development

On Wed, Mar 1, 2017 at 8:53 PM William Hermans wrote: > Jason, > > Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify > the the board overlay file. Or maybe it was one of the includes, I forget > which. > There is also a kernel module blacklist

Re: [beagleboard] Re: PRU Development

Jason, Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify the the board overlay file. Or maybe it was one of the includes, I forget which. On Wed, Mar 1, 2017 at 6:37 PM, Jason Kridner wrote: > > > On Mar 1, 2017, at 7:48 PM, William Hermans

Re: [beagleboard] Re: PRU Development

> On Mar 1, 2017, at 7:48 PM, William Hermans wrote: > > I had the PRU's working with an 4.x kernel around 4-5 months ago. Basically I > downloaded Jason's PRU github files, and got two of the examples working. > Back then, you could only use the older UIO PRU source

Re: [beagleboard] Re: PRU Development

I had the PRU's working with an 4.x kernel around 4-5 months ago. Basically I downloaded Jason's PRU github files, and got two of the examples working. Back then, you could only use the older UIO PRU source examples with the *bone* kernel, as TI's kernel was remoteproc only. Now days, supposedly

Re: [beagleboard] why is pinmux-helper needed?

On Wed, 3/1/17, John Syne wrote: Subject: Re: [beagleboard] why is pinmux-helper needed? To: "Beagle Board" Date: Wednesday, March 1, 2017, 10:26 PM You need to understand how the pins are

[beagleboard] Need help with disabling the HDMI

Hi, i am trying to disable the HDMI but i cant do it. I know I need to edit the uEnv.txt file and there are two of them. I can access the first one but can't seem to access the mounted one. I am trying to use this code : 1. mkdir /mnt/boot 2. mount /dev/mmcblk0p1 /mnt/boot 3. nano

[beagleboard] Re: BBBW answer at last Meetup

On Wed, Mar 1, 2017 at 3:45 PM Jason Kridner wrote: > On Wed, Mar 1, 2017 at 2:46 PM Thomas Livingstone > wrote: > > When you say update firmware are you referring to a different image or a > kernel. > I am doing this as a test with latest image

[beagleboard] Re: BBBW answer at last Meetup

On Wed, Mar 1, 2017 at 2:46 PM Thomas Livingstone wrote: > When you say update firmware are you referring to a different image or a > kernel. > I am doing this as a test with latest image 2016-11-06 and did do an > sudo apt-get update > sudo apt-get upgrade > Using an SD

Re: [beagleboard] why is pinmux-helper needed?

You need to understand how the pins are configured when defined in the devicetree. It is the driver that does the pin configuration as defined in the devicetree. Without an associated driver, the pins defined in the devicetree won’t do anything. When using PRU, there is no driver, so the pins

[beagleboard] Re: BBBW answer at last Meetup

When you say update firmware are you referring to a different image or a kernel. I am doing this as a test with latest image 2016-11-06 and did do an sudo apt-get update sudo apt-get upgrade Using an SD card version of that image. I am familiar with using connman and the Dec 5 testing image

Re: [beagleboard] Re: PRU Development

Once you get it working on the old stuff, come back and ask how to get it moved forward. It is pretty easy once you know your PRU code is working. With the remote-proc driver, you can throw the built .elf files into /lib/firmware and trigger them to load by the kernel, without needing to have a

[beagleboard] Re: PRU Development

Hi Mike, As Greg said, PRU development is severely hampered by incomplete, out-dated, and mutually-exclusive sets of instructions. Derek Molloy's book may be based on an older Beaglebone Black, but at least it's self-contained and consistent. I struggled for a long time to get the PRU working

[beagleboard] Re: BBGW SPI0 data corrupt

Board layout issue, crosstalk most likely On Wednesday, November 16, 2016 at 3:06:31 AM UTC+2, Joe Phaneuf wrote: > > resolved, 100pF cap on SPI0 clock near the grove connector causing > reflections, resulting in double-clocking data. sigh. > -- For more options, visit

Re: [beagleboard] Re: Mesh on BBBW

A follow up on this one. - If you are just missing the user space script to setup the mesh you can get them from https://git.ti.com/wilink8-wlan/wl18xx-target-scripts/trees/R8.7_SP1 - they are installed as part of the build script, otherwise clone them independently - The mesh patches have been

[beagleboard] Re: Mesh on BBBW

Hi Benjamin, First some background before we go into the details. There are two types of wilink8 driver deliveries - TI driver release. R8.7 is the latest. This is the full feature driver release that includes all features including mesh. It is built via the build script at the link you

[beagleboard] UART2 with RTS/CTS ...

Hi, My kernel is 3.8.13-bone69, My UART2 works without flow control (Checked with a loopback between TX and RX), But, if I enable RTS/CTS about UART2 (P8_38/P8_37) ... nothing works ! I have also a loopback between RTS and CTS ... Checked also with null modem cable and a computer ... My

Re: [beagleboard] Re: BeagleBone Black Input Voltage Range and corresponding Logic Levels?

http://www.ti.com/product/AM3358/technicaldocuments On Wed, Mar 1, 2017 at 5:31 AM, wrote: > I want to give input to beaglebone black. But my hardware (From which I am > giving input to beaglebone) Toggles between 0.5V and 3.3V. My question is > till what

[beagleboard] Re: BeagleBone Black Input Voltage Range and corresponding Logic Levels?

I want to give input to beaglebone black. But my hardware (From which I am giving input to beaglebone) Toggles between 0.5V and 3.3V. My question is till what voltage beaglebone will take it as logic 0 On Sunday, March 8, 2015 at 5:48:49 PM UTC+5:30, COG wrote: > > Hi: > > I would like to

[beagleboard] Re: BeagleBone Black Input Voltage Range and corresponding Logic Levels?

I want to give input to beaglebone black. But my hardware (From which I am giving input to beaglebone) Toggles between 0.5V and 3.3V. My question is till what voltage beaglebone will take it as logic 0 On Sunday, March 8, 2015 at 5:48:49 PM UTC+5:30, COG wrote: > > Hi: > > I would like to

Re: [beagleboard] Re: BeagleBone Black Input Voltage Range and corresponding Logic Levels?

http://www.ti.com/product/AM3358/technicaldocuments Gerald On Wed, Mar 1, 2017 at 1:25 AM, wrote: > > > On Sunday, March 8, 2015 at 5:48:49 PM UTC+5:30, COG wrote: >> >> Hi: >> >> I would like to know (preferably from a datasheet or similar) the *input >>

[beagleboard] Re: How to flash custom BBB image created with Buildroot into eMMC?

Update I managed to get BBBfls running and tried it ( http://ungureanuvladvictor.github.io/BBBlfs/) - "option 2" - xz image created with buildroot. Image is booting fine from SD card (based on latest Buildroot Beaglebone_defconfig) End result was fail, unfortunately. The BBBlfs complains

Re: [beagleboard] SPI Woes with different Kernel Versions

The Loopback test only involves MISO and MOSI lines that leaves CS and CLK as potential source of errors. I have made some measurements with an oscilloscope and it shows two notable differences between 4.4 and 3.8: - For 3.8 CS toggles between high and low. For 4.4 CS is always low after an

[beagleboard] Mesh on BBBW

I am trying to setup the BBB Wireless for mesh functionality, however i noticed that all the files for the wilink 8 required are not even built. I am doing the tutorial from http://www.ti.com/lit/an/swaa166/swaa166.pdf and realise that the files are missing from /usr/share/wl18xx/ can

[beagleboard] Re: BeagleBone Black Input Voltage Range and corresponding Logic Levels?

On Sunday, March 8, 2015 at 5:48:49 PM UTC+5:30, COG wrote: > > Hi: > > I would like to know (preferably from a datasheet or similar) the *input > voltage ranges* that would equate to a '*logic low*' and a '*logic high*' > for the BBB? > > Here is an example of what I am talking about: > See

[beagleboard] BoneScript 0.6.1 released

BoneScript is back under active development after another fairly log hiatus. New in 0.6.0: * Fixed dependencies to run on node 4.x and some newer versions. Running node older than 0.12 should be mostly broken now. New in 0.6.1: * Force usage of hw_mainline on kernels 4.4.x and newer, even if