Re: [beagleboard] Fundamental capemanager change between 4.1.x, and 4.4.x

Just for added measure, yes the UIO driver does work . . william@beaglebone:~$ lsuio uio0: name=tscadc, version=devicetree, events=0 map[0]: addr=0x44E0D000, size=4096 On Thu, Apr 21, 2016 at 9:51 PM, William Hermans wrote: > Ok, so the following does *NOT* work on

[beagleboard] Fundamental capemanager change between 4.1.x, and 4.4.x

Ok, so the following does *NOT* work on a 4.4.x kernel, but does on a 4.1.x kernel. *Starting off with 4.4.x kernel* william@beaglebone:~$ cat ti/WH-ADC-00A0.dts /dts-v1/; /plugin/; / { compatible = "ti,beaglebone", "ti,beaglebone-black"; /* identification */

Re: [beagleboard] High CPU usage after loading a cape on Jessie

Also oddly enough, that method for loading an uio driver, at least the demonstration uio driver for ADC is broken. Exact step instructions I've created and tested personally no longer work. At least on my BBB with . . . william@beaglebone:~$ uname -r 4.4.7-bone-rt-r9 william@beaglebone:~$ cat

Re: [beagleboard] High CPU usage after loading a cape on Jessie

Anyway, if you have a device tree "compatible=uio" definition for any node in any device tree. It seems that udev rule will hammer the crap out of the system until the udev rule can actually do what it wants to. On Thu, Apr 21, 2016 at 9:05 PM, William Hermans wrote: >

Re: [beagleboard] High CPU usage after loading a cape on Jessie

@Robert, I think I found the answer to your question. From a text file based on something another person on these forums was discussing with me . . . # put in /etc/modprobe.d/uio.conf # # make driver match on compatible = "uio"; options uio_pdrv_genirq of_id=uio # put in

Re: [beagleboard] High CPU usage after loading a cape on Jessie

On Thu, Apr 21, 2016 at 10:04 PM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > On 4/21/2016 9:43 PM, Charles Steinkuehler wrote: > > On 4/21/2016 9:37 PM, Robert Nelson wrote: > >> > >> Does the uio_pruss still work if we just nuke that whole udev rule?? > > > > Testing > Thanks

Re: [beagleboard] High CPU usage after loading a cape on Jessie

On 4/21/2016 9:43 PM, Charles Steinkuehler wrote: > On 4/21/2016 9:37 PM, Robert Nelson wrote: >> >> Does the uio_pruss still work if we just nuke that whole udev rule?? > > Testing Commenting the first line (with SYMLINK+=): == No excessive CPU usage when loading a PRU device-tree

Re: [beagleboard] High CPU usage after loading a cape on Jessie

Robert, Charles, One thing that confused me, was why does the uio_pruss driver add 8 mmap() file objects in that /dev/uio directory structure. They all point to the same address in memory it seems too. Also according to older exact step how-to's from aroudn 2013-2014, this hs omehow changed

Re: [beagleboard] High CPU usage after loading a cape on Jessie

On Thu, Apr 21, 2016 at 9:01 PM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > On 4/21/2016 7:41 PM, Charles Steinkuehler wrote: > > On 4/21/2016 7:32 PM, Robert Nelson wrote: > >> On Thu, Apr 21, 2016 at 7:25 PM, Charles Steinkuehler < > char...@steinkuehler.net > >>

Re: [beagleboard] High CPU usage after loading a cape on Jessie

> > *After further testing, if you create a /dev/uio directory before* > * trying to load a uio driver (like the PRU driver), everything works* > * fine. Interestingly, there are *NO* symlinks actually generated in* > * the /dev/uio directory, but the simple fact that it exists seems to be* > *

Re: [beagleboard] High CPU usage after loading a cape on Jessie

On 4/21/2016 7:41 PM, Charles Steinkuehler wrote: > On 4/21/2016 7:32 PM, Robert Nelson wrote: >> On Thu, Apr 21, 2016 at 7:25 PM, Charles Steinkuehler >> > > wrote: >> >> and of course, i never added who pinged me on this, when i

Re: [beagleboard] uio_pruss on Mainline Linux

> > * That reminds me of the 68000 CPU manuals back in the day (when* > * you actually had dead-tree printed book data-sheets). The first* > * edition was *HUGE* (about 2 inches thick), but after several years had* > * gone by, the manual was only about 1/2 an inch thick. They had* > * removed

Re: [beagleboard] uio_pruss on Mainline Linux

But this was done a while ago when the added support for ethernet. I’m not aware of any other changes. Regards, John > On Apr 21, 2016, at 5:21 PM, Robert Nelson wrote: > > > > On Thu, Apr 21, 2016 at 7:09 PM, Jordan Yelloz

Re: [beagleboard] uio_pruss on Mainline Linux

On 4/21/2016 7:37 PM, William Hermans wrote: > I had someone on this group tell me not long ago that I must be joking when I > tried to explain I was note sure how something worked with remoteproc on the > PRU's. But see that the problem when you're dealing with someone whose known > the >

Re: [beagleboard] High CPU usage after loading a cape on Jessie

On 4/21/2016 7:32 PM, Robert Nelson wrote: > On Thu, Apr 21, 2016 at 7:25 PM, Charles Steinkuehler > > wrote: > > OK, this doesn't appear to be a PRU issue, it's a fundamental problem > with udev. The systemd-udevd process

Re: [beagleboard] uio_pruss on Mainline Linux

> > *Thanks, that appears to be a pretty small patch, I'll try it out.* > *I would have no problem using the remoteproc_pruss if it was in the > official kernel but I can't see any as of 4.6-rc4.* > The main problem I see with remoteproc is that it is not as well documented as uio_pruss. Many

Re: [beagleboard] High CPU usage after loading a cape on Jessie

On Thu, Apr 21, 2016 at 7:25 PM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > On 4/10/2016 3:36 PM, Charles Steinkuehler wrote: > > On 4/10/2016 3:17 PM, Charles Steinkuehler wrote: > >> On 4/10/2016 11:13 AM, Charles Steinkuehler wrote: > >>> I am experimenting with getting

Re: [beagleboard] High CPU usage after loading a cape on Jessie

On 4/10/2016 3:36 PM, Charles Steinkuehler wrote: > On 4/10/2016 3:17 PM, Charles Steinkuehler wrote: >> On 4/10/2016 11:13 AM, Charles Steinkuehler wrote: >>> I am experimenting with getting Machinekit running on Debian Jessie, >>> and have run into an issue with loading capes. >>> >>> After I

Re: [beagleboard] uio_pruss on Mainline Linux

On Thu, Apr 21, 2016 at 7:09 PM, Jordan Yelloz wrote: > Thanks, that appears to be a pretty small patch, I'll try it out. > I would have no problem using the remoteproc_pruss if it was in the > official kernel but I can't see any as of 4.6-rc4. > remoteproc_pruss is

[beagleboard] Re: Extracting eMMC contents using FAT formatted card

I had this same problem. I hadn't set the SD disk partition to "ACTIVE". Once I did that the LEDs came on. On Monday, March 9, 2015 at 9:58:15 AM UTC-7, Felipe ordoñez wrote: > > Hi, > > I have tried to save my information with this procedure, but when the BBB > start (Power led ON), with

Re: [beagleboard] uio_pruss on Mainline Linux

Thanks, that appears to be a pretty small patch, I'll try it out. I would have no problem using the remoteproc_pruss if it was in the official kernel but I can't see any as of 4.6-rc4. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are

Re: [beagleboard] uio_pruss on Mainline Linux

On Thu, Apr 21, 2016 at 6:41 PM, Jordan Yelloz wrote: > Hi, I've been wondering for a while, since there is a driver in mainline > Linux called uio_pruss, what can we actually do with it? Does it work with > the beaglebone black? I have built Linux 4.5.2 with this

[beagleboard] uio_pruss on Mainline Linux

Hi, I've been wondering for a while, since there is a driver in mainline Linux called uio_pruss, what can we actually do with it? Does it work with the beaglebone black? I have built Linux 4.5.2 with this support enabled (i've tried a few other versions too) but there's no information on what

Re: [beagleboard] BeagleBone Black RTC Wake Alarms

drivers/soc/ti/wkup_m3_ipc.c Also from memory has nothing to do with the rtc wakeup stuff. That actually is for the PRU's or possibly other peripherals sharing the L3 interconnect fabric on the am335x processor. Sorry, I missed that the first time I read your post. On Thu, Apr 21, 2016 at 3:26

Re: [beagleboard] Spurious power button press with new Debian

Sorry, and actually there should be no white spaces in that period. So . . . cmdline=kernel.nmi_watchdog=0 On Thu, Apr 21, 2016 at 3:42 PM, William Hermans wrote: > *With the newest Debian distro, whenever I do that, I get a message that >> the power button has been

Re: [beagleboard] Spurious power button press with new Debian

> > *With the newest Debian distro, whenever I do that, I get a message that > the power button has been pressed, and the BBB simply shuts down after > that. * > > Any ideas on what might have changed in the OS for this to happen? Code I could not say what exactly has changed, but I can say

Re: [beagleboard] BBB GPIO access with java

Any file system *LIBRARY* . . . . typo. On Thu, Apr 21, 2016 at 3:27 PM, William Hermans wrote: > Any file system linrary would work, with the knowledge of how sysfs works. > > On Thu, Apr 21, 2016 at 10:13 AM, wrote: > >> Hello! >> >> Did someone

Re: [beagleboard] BBB GPIO access with java

Any file system linrary would work, with the knowledge of how sysfs works. On Thu, Apr 21, 2016 at 10:13 AM, wrote: > Hello! > > Did someone know a good free LIB for accessing the GPIO from the > Beaglebone Black? > I know: > http://libbulldog.org/bulldog/ > > But not

Re: [beagleboard] BeagleBone Black RTC Wake Alarms

I can tell you that using kernel 4.1.x https://www.linux.com/learn/wake-linux-rtc-alarm-clock works. I'm not sure that rtc wake timer is related to the one you're asking. However, I can tell you that once the main am335x processor loses power, or the ability to act from being in sleep mode, the

Re: [beagleboard] Connecting USB device into GPIO ?

There are some BLE SPI modules out there, and *maybe* some I2C BLE modules. The BBB does have both SPI and I2C. On Thu, Apr 21, 2016 at 1:41 PM, Robert Nelson wrote: > > > On Thu, Apr 21, 2016 at 1:08 PM, wrote: > >> As topic leads, can a USB

Re: [beagleboard] My overlay can't find clk_mcasp0

I don't have the BBB connected at the moment, but if I don't get you the configuration by tonight, please feel free to email me again. > On Apr 21, 2016, at 14:40 , Rafael Vega wrote: > > I've made some progress but I still can't get any sound from the codec. I > tried

Re: [beagleboard] My overlay can't find clk_mcasp0

I've made some progress but I still can't get any sound from the codec. I tried the two approaches suggested by Rick M earlier on this thread: 1) To use this dtb by Rick M and the audio cape overlay, and 2) to use this

Re: [beagleboard] Connecting USB device into GPIO ?

On Thu, Apr 21, 2016 at 1:08 PM, wrote: > As topic leads, can a USB device be hooked into GPIO's? > I need Wifi and BLE devices in BBG but dues one USB its one or other. So > since BLE uses less power i wonder if im able to connect BLE dongle into > GPIO's instead ? > I

[beagleboard] BeagleBone Black RTC Wake Alarms

I am trying to use power management (sleep mode) in a way that is similar to how Android does it with timerfd and epoll. I want to enable autosleep and use RTC wake timers (created using timerfd) that wake the system back up and prevent sleep mode (using epoll mechanism) until the timer event

[beagleboard] Connecting USB device into GPIO ?

As topic leads, can a USB device be hooked into GPIO's? I need Wifi and BLE devices in BBG but dues one USB its one or other. So since BLE uses less power i wonder if im able to connect BLE dongle into GPIO's instead ? I would guess this is question for both hardware and software topics. --

[beagleboard] Spurious power button press with new Debian

Hello guys, I have a custom carrier board powering my Beaglebone Black through the 5V supply pins on P9 (pins 5+6, I believe). Because I'm having issues getting my working legacy Angstrom distribution image cloned onto new boards that have Micron flash instead of Kingston, I decided to give a

[beagleboard] BBB GPIO access with java

Hello! Did someone know a good free LIB for accessing the GPIO from the Beaglebone Black? I know: http://libbulldog.org/bulldog/ But not sure if I make mistakes ... very often I cannot inititalize: private final Board board = Platform.createBoard(); This happens, when I destroy my class. I do

[beagleboard] Re: Is is possible to communicate over serial (big USB ) between BBB and Teensy 2.0?

Hi, on the BBB the USB host device appears as ttyACM* for many of serial devices, or ttyUSB* you can assured by using: ls -l /dev/ttyACM* ls -l /dev/ttyUSB* after you found your device you can use pyserial or any other libraries to communicate! good luck! On Sunday, November 9, 2014 at

Re: [beagleboard] My overlay can't find clk_mcasp0

> > *Yeah, that's the file that's working for me, EXCEPT: I modified my > am33xx-overlay-edma-fix.dtsi to comment out the two mcasp entries. If I > boot with that (on 4.4.7-bone-rt-r9), then I can load the BB-BONE-AUDI-02 > overlay, and then I can use aplay and speaker-test.* > > * At this point,

Re: [beagleboard] BeagleBone Black n00b - maybe already corrupted eMMC?

> > *The cheapest solution right now to safe guard from unexpected power > outages. Is to buy a battery, and connect it to the PMIC test points. This > will give the beaglebone enough time to issue a clean shutdown after input > power goes missing. And that it exactly what it will do, power

Re: [beagleboard] BeagleBone Black n00b - maybe already corrupted eMMC?

> > *In the real world, BBBs and other devices will experience unexpected and > unplanned power outages, should be designed, and up to a reasonable point > are designed to survive them. I have both intentionally and unintentionally > rudely removed power from BBBs many, many times (hundreds?) with

Re: [beagleboard] Flashin BBB with new image I built from RC guide

Doh thank you that did it Thanks again for the hand holding. On Wednesday, April 20, 2016 at 3:56:47 PM UTC-7, RobertCNelson wrote: > > > > On Wed, Apr 20, 2016 at 5:40 PM, Matt99eo > wrote: > >> Yes I saw this stuff and used the >> >> /dev/sdX options to get it all on

Re: [beagleboard] My overlay can't find clk_mcasp0

> > Are you able to make it work with my original .dtb and loading the > BB-BONE-AUDI-02 overlay via capemgr? > > When I do this, the overlay loads fine and I can see the mcasp0 pins being driven by the BBB when I start aplay or speaker-test. However, I can't see any analog signals coming

[beagleboard] Re: BeagleBoard (Angstrom Linux distribution) - How to get USB WEB camera working

I wish someone had answered this. On Wednesday, September 5, 2012 at 4:53:34 AM UTC-4, Krcevina wrote: > > Hi, > > I have downloaded MLO, u-boot.img and uImage from > http://downloads.angstrom-distribution.org/demo/beagleboard/ and my BB > boots okay. When I connect USB WEB camera with BB I

Re: [beagleboard] updated config-pin?

Were you able to solve this problem? On Friday, October 23, 2015 at 7:51:35 AM UTC-7, Yogi Patel wrote: > > On Friday, October 23, 2015 at 9:31:57 AM UTC-4, RobertCNelson wrote: >> >> On Thu, Oct 22, 2015 at 8:04 PM, wrote: >> > Hi - >> > >> > I just our project to 4.1. I

Re: [beagleboard] How to use Exim4 to Send Email from Beaglebone Black Debian

Create the file .muttrc eg in /root/ or in /home/debian/ (the user that wants to use mutt) and add a line set smtp_url="smtp://user:passw...@smtp.someserver.com" And don't forget the return after this line. (as in crontab as well) * * * * * root ls /somefolder | mutt -s ""

[beagleboard] Re: Up to 4 axis CNC cape for Beaglebone Black on Kickstarter

What is the difference to https://halaser.eu/e1701p.php or https://halaser.eu/e1701m.php ? Am Dienstag, 12. April 2016 23:32:48 UTC+2 schrieb Andy: > > Hi, > > I like to inform you about a new Kickstarter Project. > The project will provide an opto coupled CNC cape for the Beaglebone Black. > >

Re: [beagleboard] My overlay can't find clk_mcasp0

> On Apr 20, 2016, at 23:52 , William Hermans wrote: > > Rick, ah I gotcha now I guess. I'd have to use this -> > http://pastebin.com/Wja7ZQRk edit out the edma include line, compile, and > then load that up as my dtb= line. Then, perhaps the audio cape will load. It >

Re: [beagleboard] My overlay can't find clk_mcasp0

Yeah, right now I'm just trying to get the audio cape to load. The audio cape of our project is actually one of two potential daughter capes, and we're not in a huge hurry to figure all that out. But I figured since you all are doing this, now I'd join in and see if i could help or not. Plus, yes,