Re: [beagleboard] ARM->PRU->ARM interrupts for data transfer from ARM->PRU

> > awesome! Thank you! Do you know where I can find a good example of using > shared memory? I am wondering if I might be better off using shared memory > instead. Does shared memory work both ways so that ARM can access the PRU > memory and PRU access the ARM memory? > There is a DDR

Re: [beagleboard] configure USB using Scilab

More information is needed. On Wed, Oct 12, 2016 at 1:28 PM, NOUHA el mehri wrote: > hi, i am working in a project i need to configure the usb0 and replace > the port ttycom0 by usb0 using scilab i used a comand genlib but it didnt > work if anybody can help me by

Re: [beagleboard] bone_capemgr bone_capemgr: loader: failed to load slot-4 (prio 0)

;,/* EHRPWM1B */ "P9.21",/* EHRPWM0A */ "P9.22",/* EHRPWM0B */ "P9.23", "P9.25", "P9.27", "P9.28", "P9.29", "P9.30", "P9.31",

Re: [beagleboard] bone_capemgr bone_capemgr: loader: failed to load slot-4 (prio 0)

By the way, this has been tested consistently on one BBB RevC, and several( tens ) of BBG's. By me personally, and another person, elsewhere. On Wed, Oct 12, 2016 at 6:33 PM, William Hermans <yyrk...@gmail.com> wrote: > So I've been searching the groups here for the last several ho

[beagleboard] bone_capemgr bone_capemgr: loader: failed to load slot-4 (prio 0)

So I've been searching the groups here for the last several hours. I've tried several things, even noted that the device tree "binary" file (compiled file in /lib/firmware) was marked as executable. So I set the executable bit via chmod -x . . .Anyway, this is a custom device tree overlay

Re: [beagleboard] Question about /lib/modules on BeagleBoard-xm running Jessie

-bone-rt-r10 dtbs uEnv.txt vmlinuz-4.4.9-bone-rt-r10 On Tue, Oct 11, 2016 at 7:46 PM, William Hermans <yyrk...@gmail.com> wrote: > If you look in /boot, you should also see the same drectories. But since > module are compiled against a kernel, on a per kernal bas

Re: [beagleboard] Question about /lib/modules on BeagleBoard-xm running Jessie

If you look in /boot, you should also see the same drectories. But since module are compiled against a kernel, on a per kernal basis. You need new modules for a new kernel. e.g. you probably have had two different kernels installed. On Tue, Oct 11, 2016 at 7:44 PM, David Glaser

Re: [beagleboard] How to change default hwclock on BBB Debian to always be /dev/rtc1?

The best way I found for myself. Was to simply install ntpdate, run it, then update the external real clock from system time. Then, if you *absolutely* need rtc0 updated. You update it from the system time. Or rtc1. No need to recompile the kernel. Sure, it's a couple of extra steps, but steps

Re: [beagleboard] SGX on 4.4.*-ti-rt kernel

On Tue, Oct 4, 2016 at 6:05 PM, Matthijs van Duin <matthijsvand...@gmail.com > wrote: > On 5 October 2016 at 02:43, William Hermans <yyrk...@gmail.com> wrote: > >> So libEGL is Mesa's Wayland extensions. >> > > No. > > <https://en.wikipedia.org/wiki/EG

Re: [beagleboard] SGX on 4.4.*-ti-rt kernel

On Tue, Oct 4, 2016 at 12:24 PM, Matthijs van Duin < matthijsvand...@gmail.com> wrote: > On Wednesday, 28 September 2016 11:05:50 UTC+2, Matteo Facchinetti wrote: >> >> libEGL warning: DRI3: xcb_connect failed >> libEGL warning: DRI2: xcb_connect failed >> libEGL warning: DRI2: xcb_connect failed

Re: [beagleboard] Re: init-eMMC-flasher mmcqd allocation failures

. It's not looking likely, but not impossible. On Tue, Oct 4, 2016 at 5:27 PM, William Hermans <yyrk...@gmail.com> wrote: > Instead of deferring until memory is available, or even just proceeding >> without DMA, the omap_hsmmc driver immediately fails the request with an >&g

Re: [beagleboard] Re: init-eMMC-flasher mmcqd allocation failures

> > Instead of deferring until memory is available, or even just proceeding > without DMA, the omap_hsmmc driver immediately fails the request with an > error, thus pretty much guaranteeing loss of data or even filesystem > corruption. I personally think this is completely unacceptable behaviour

Re: [beagleboard] angstrom image

Everything one needs is right here: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian Including links to the latest images. On Sun, Oct 2, 2016 at 1:22 PM, Stephane Charette < stephanechare...@gmail.com> wrote: > On Sunday, October 2, 2016 at 1:10:34 PM UTC-7, Wulf Man wrote: >> >> try a

Re: [beagleboard] BBB Flashing new image

Try reading this: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC Suitable images are also listed on that page. On Sat, Oct 1, 2016 at 3:56 PM, William Hermans <yyrk...@gmail.com> wrote: > Not all images blink the LEDs. It's not that common, but I've run into at &g

Re: [beagleboard] BBB Flashing new image

Not all images blink the LEDs. It's not that common, but I've run into at least one such image in the last year or so. On Sat, Oct 1, 2016 at 3:28 PM, Paul P wrote: > Hello, > > I'm trying flash kali linux or debian onto BBB with zero success for some > reasons. > > I did

Re: [beagleboard] Re: question from a total newbie...

> > . . .and the chances you'll need a cross compiler toolchain, and IDE are > near nil. > For your own code. Unless you're one of *those* (them?!) code zombies who eat's sleeps and breathes caffine. Writing 5M lines of bug ridden code a day ;) On Fri, Sep 30, 2016 at 6:37 PM, Wil

Re: [beagleboard] Re: question from a total newbie...

is your imagination. On Fri, Sep 30, 2016 at 5:41 PM, William Hermans <yyrk...@gmail.com> wrote: > Well, there seems to be a lot of confusion between toolchains, which no > one really asked or said anything about( I made a passing remark ), Linux > kernel, and Linux image. My o

Re: [beagleboard] Re: question from a total newbie...

Well, there seems to be a lot of confusion between toolchains, which no one really asked or said anything about( I made a passing remark ), Linux kernel, and Linux image. My own idea of what makes a Linux image is a complete "package" that contains bootloader(s), a Linux kernel, and a rootfs(root

Re: [beagleboard] BeagleBoard-X15 production board update

> > The discoloration in now way affects the operation of the board, it is > just a side affect of the heat generated by the processor. > In no way ? Just want to be clear. I have overactive fingers sometimes too. On Fri, Sep 30, 2016 at 10:39 AM, Gerald Coley wrote: >

Re: [beagleboard] Re: numpy won't install for me

$ ls . Would determine if the script is in the current working directory. On Thu, Sep 29, 2016 at 5:05 PM, Dennis Lee Bieber wrote: > On Thu, 29 Sep 2016 15:35:57 -0700 (PDT), Lidia Toscano > declaimed the > following: > > >Hi, I am running

Re: [beagleboard] Re: question from a total newbie...

Not only that but if you make a mistake, and render the eMMC unbootable. How would you fix it without an sdcard ? Short answer is that you can't. But with an sdcard, you'd insert the "emergency" card, revert the changes you made, then power cycle the board ater removing the sdcard. viola! problem

Re: [beagleboard] Re: question from a total newbie...

compiler. On Thu, Sep 29, 2016 at 4:57 PM, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote: > On Thu, 29 Sep 2016 14:12:56 -0700, William Hermans > <yyrk...@gmail.com> declaimed the following: > > >The hard part would mostly be finding good solid information on how t

Re: [beagleboard] Re: question from a total newbie...

the groups here of people having issues with creating images that work on both . . . again your mileage may vary. On Thu, Sep 29, 2016 at 4:44 PM, William Hermans <yyrk...@gmail.com> wrote: > mzimmers, > > Do yourself a favore and get this book: https://www.amazon.com/ > Exp

Re: [beagleboard] Re: question from a total newbie...

n than you absorb in several months. It'll make an excellent reference. On Thu, Sep 29, 2016 at 4:35 PM, William Hermans <yyrk...@gmail.com> wrote: > Thanks for the detailed answers. Do I really need to use an SD card for >> transferring the kernel to the beaglebone? See

Re: [beagleboard] Re: question from a total newbie...

> > Thanks for the detailed answers. Do I really need to use an SD card for > transferring the kernel to the beaglebone? Seems kind of cumbersome, so if > there's another way to do it, I'd appreciate hearing about it. > No you do not. You could create a *deb file, or other package manager file

Re: [beagleboard] Re: question from a total newbie...

> > Dont treat this as an rPI endorsement however. I much prefer the > beaglebone in most cases, but the rPI, specifically the rPI's has many good > points too. > Raspberry PI 3 On Thu, Sep 29, 2016 at 2:33 PM, William Hermans <yyrk...@gmail.com> wrote: > > > O

Re: [beagleboard] Re: question from a total newbie...

On Thu, Sep 29, 2016 at 2:25 PM, Graham Haddock wrote: > Hi William: > > For an expert, you are totally correct. > I would argue the other way around. the rPI's have stuff like 'wiring', and are a lot like the Arduino's in many ways. Only running Linux. Me, I'm not a big

Re: [beagleboard] Re: question from a total newbie...

n Thu, Sep 29, 2016 at 2:12 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Thu, Sep 29, 2016 at 2:04 PM, Graham <gra...@flex-radio.com> wrote: > >> The Beaglebone is a better choice than say, Raspberry Pi, since Linux is >> somewhat locked-down

Re: [beagleboard] Re: question from a total newbie...

On Thu, Sep 29, 2016 at 2:04 PM, Graham wrote: > The Beaglebone is a better choice than say, Raspberry Pi, since Linux is > somewhat locked-down on the R Pi, which puts limits what you can do with it. > This is mostly false. The images provided by the Raspberry PI

Re: [beagleboard] question from a total newbie...

By the way the beaglebone comes with a pre-installed Linux demo image already on it. On the eMMC. So no sdcard is required, but is recommended. On Thu, Sep 29, 2016 at 2:00 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Thu, Sep 29, 2016 at 11:39 AM, mzimmers <mzimm..

Re: [beagleboard] Pinmux Problems

> > The dtc version on recent images is 1.4.1, but the version used by the > 3.8.13 kernel is 1.2.0-g37c0b6a0. If I use the dtc from the kernel > source I can happily load a freshly compiled overlay. > It should be 1.4.0 for 3.8.x kernels. As I recall. On Sun, Sep 25, 2016 at 8:26 AM, Charles

Re: [beagleboard] Making Beagleboard-xm appear as a joystick to pc host

For a USB HID, according to what I've read. You do not need to worry about all that. You just need to write or have an HID descriptor file. On Fri, Sep 23, 2016 at 8:56 AM, Theodore A. Roth wrote: > On Fri, Sep 23, 2016 at 9:21 AM, David Glaser >

Re: [beagleboard] Making Beagleboard-xm appear as a joystick to pc host

may as well start off with a "bare metal" type device. Cost, and complexity wise you're life will be a lot simpler. With the trade-off that you'll have to get your hands dirty writing low level code( at the register level ). On Thu, Sep 22, 2016 at 4:53 PM, William Hermans <yyrk...@gma

Re: [beagleboard] Making Beagleboard-xm appear as a joystick to pc host

on the beagelbone ). Then the idea becomes writing client / server app(s) for which the sky is the limit. On Thu, Sep 22, 2016 at 4:43 PM, William Hermans <yyrk...@gmail.com> wrote: > Searching the internet, you're likely going to find people who say this is > not possible. At least where USB

Re: [beagleboard] Making Beagleboard-xm appear as a joystick to pc host

Searching the internet, you're likely going to find people who say this is not possible. At least where USB is concerned. Where the RasberryPI is concerned the USB ports on it are connected to a hub chip, which then runs in USB master mode. So . . . using HID USB descriptors is not possible in

Re: [beagleboard] Re: Trying to run the ADC from the PRU

> > The only device tree overlay I needed is what I have below; no need to > load the BB-ADC overlay. > Right, technically, you do not need an overlay, and you do not need any driver modules either. As directly twiddling the ADC module registers, you essentially are creating your own driver.

Re: [beagleboard] Compilation fails with dtsi file not found.

> > That pretty much mean if file /sys/bus/w1/devices/28-*/w1_slave exists -> > modprobe > w1-gpio -> load the BB-W1-P9.12 file into capemanager > then of course -> sleep for 1 second. > If file DOESNT exist. Sorry I missed the exclamation mark there initially. which is boolean NOT. On Tue,

Re: [beagleboard] Compilation fails with dtsi file not found.

9.12 file into capemanager then of course -> sleep for 1 second. If you need a different pin for one wire, then you'll have use another device tree file in place of BB-W1-P9.12 On Tue, Sep 20, 2016 at 1:10 PM, William Hermans <yyrk...@gmail.com> wrote: > It'll load the w1( one wire ) driver

Re: [beagleboard] Compilation fails with dtsi file not found.

It'll load the w1( one wire ) driver module if not already loaded, then it'll get the temperature from the device every 5 seconds. It'll also load the BB-W1-P9.12 device tree file. I'd assume you'd need to edit this file, or change the overlay file to be loaded if you need to use a different pin.

Re: [beagleboard] Compilation fails with dtsi file not found.

One more thing. make sure all other cmdline= lines are also commented out. As the last line will likely override previous lines. On Tue, Sep 20, 2016 at 12:05 PM, William Hermans <yyrk...@gmail.com> wrote: > cmdline=coherent_pool=1M quiet > > *cape_universal=enable* > Remov

Re: [beagleboard] Compilation fails with dtsi file not found.

cmdline=coherent_pool=1M quiet *cape_universal=enable* Remove, the bolded text. Or better yet, copy that line. Remove that text, then comment out the original line. On Tue, Sep 20, 2016 at 12:00 PM, cory cauvier wrote: > just got the newest version now I'm looking to do

Re: [beagleboard] 2016 09 09 BBB eMMC Flasher image fails to boot eMMC after powerdown

err, so in a pinch or just outright one could use that image, and upgrade the kernel if need be later. Through APT. Assuming that image would work for the OP here . . . On Tue, Sep 20, 2016 at 10:28 AM, William Hermans <yyrk...@gmail.com> wrote: > BBB-blank-debian-8.5-console-armhf-2

Re: [beagleboard] 2016 09 09 BBB eMMC Flasher image fails to boot eMMC after powerdown

BBB-blank-debian-8.5-console-armhf-2016-06-19-2gb.img.xz That's the image I've been using. It's worked on an Element14 RevC, and an Element14 BBG. I haven't tried on my A5A. . . On Tue, Sep 20, 2016 at 10:17 AM, Robert Nelson wrote: > On Tue, Sep 20, 2016 at 12:05 PM,

Re: [beagleboard] 2016 09 09 BBB eMMC Flasher image fails to boot eMMC after powerdown

https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSDcard Granted . . . sudo sfdisk ${DISK} <<-__EOF__ *4M*,,L,* __EOF__ Thats different form what I remember. I thought that was supposed to be 1M ? On Tue, Sep 20, 2016 at 10:13 AM, William Hermans

Re: [beagleboard] 2016 09 09 BBB eMMC Flasher image fails to boot eMMC after powerdown

> > That image is not working for me either. > > If I am following this, there is an issue where the eMMC is being > partitioned as if it is 4G instead of 2G correct ? > > If I just modify the sfdisk portion of the Flash script will that correct this ? It's a little more complex than that. 1)

Re: [beagleboard] Re: BBB doesn't boot after inserting uSD card having linux, even after pressing the S2 button for long

zImage is the old way Robert *used* to build kernels. As in . . . http://www.embeddedhobbyist.com/2013/07/beaglebone-black-usb-boot/ Look towards the bottom where I discuss mkimage. But anyway that post I made way back in july 2013, and it's very outdated. It's not how things are done any more.

Re: [beagleboard] Trying to run the ADC from the PRU

just used that. On Tue, Sep 20, 2016 at 7:20 AM, Phil <phil.s@gmail.com> wrote: > On Thursday, September 15, 2016 at 4:36:19 PM UTC-5, William Hermans wrote: >> >> The PRU hads to access the ADC through the L3_interconnect bus too . . . >> so the control register

Re: [beagleboard] Re: How to Send email via Beaglebone Black?

If you google "how to linux email command line" You'll see you do not need anything special to send emails from Linux . . . On Mon, Sep 19, 2016 at 10:37 PM, Hồng Quân Nguyễn wrote: > > I use mailgun.com to send email. It provides HTTP API. > > Here is a part of my code

Re: [beagleboard] 2016 09 09 BBB eMMC Flasher image fails to boot eMMC after powerdown

On Mon, Sep 19, 2016 at 6:45 PM, Robert Nelson wrote: > > > What's odd about those.. When the u-boot.img got too fat, it would > clober the partition table at 1MB, BUT from the log: > > Formatting: /dev/mmcblk1 > sfdisk: [sfdisk from util-linux 2.25.2] > sfdisk: [sfdisk

Re: [beagleboard] 2016 09 09 BBB eMMC Flasher image fails to boot eMMC after powerdown

, Sep 19, 2016 at 6:37 PM, William Hermans <yyrk...@gmail.com> wrote: > . . . > > TFTP from server 0.0.0.0; our IP address is 206.223.20.131; sending through > gateway 206.223.20.1 > Filename 'boot.scr.uimg'. > Load address: 0x8200 > Loading: * *TFTP error: 'File no

Re: [beagleboard] 2016 09 09 BBB eMMC Flasher image fails to boot eMMC after powerdown

. . . TFTP from server 0.0.0.0; our IP address is 206.223.20.131; sending through gateway 206.223.20.1 Filename 'boot.scr.uimg'. Load address: 0x8200 Loading: * *TFTP error: 'File not found' (1) Not retrying...* => On Mon, Sep 19, 2016 at 6:35 PM, Robert Nelson

Re: [beagleboard] Re: BBB doesn't boot after inserting uSD card having linux, even after pressing the S2 button for long

As with anything else computer related. You should be mindful of where you get your OS images from. Clearly the one the OP is working with is not a standard "official" image. Since Robert has not built any using a FAT partition in quite some time. As in more than a year ago. So in order to get

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

patch looks interesting. Maybe the same issue? > > https://patchwork.kernel.org/patch/9005611/ > > > Brian > > > On Thursday, September 15, 2016 at 6:45:04 AM UTC-7, Mark A. Yoder wrote: >> >> William: >> Thanks for looking into it. It looks like you got a

Re: [beagleboard] Re: BBB doesn't boot after inserting uSD card having linux, even after pressing the S2 button for long

of these 4 kernel directory "trees" that I show listed in my last command. simply by editing the "uname_r" parameter in the /boot.uEnv.txt file. On Mon, Sep 19, 2016 at 3:07 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Mon, Sep 19, 2016 at 2:53 PM, Denn

Re: [beagleboard] Re: BBB doesn't boot after inserting uSD card having linux, even after pressing the S2 button for long

On Mon, Sep 19, 2016 at 2:53 PM, Dennis Lee Bieber wrote: > On Sun, 18 Sep 2016 21:19:49 -0700 (PDT), Viswadeep Sarangi > declaimed the > following: > > > {I was running late getting to work and missed this part} > > >The contents of the FAT

Re: [beagleboard] Sharing WiFi connection with BBB using Debian

On Mon, Sep 19, 2016 at 12:05 PM, shewhorn wrote: > I posted something yesterday but it seems to have vanished. I've run into > this difficult before where none of the instructions or tutorials for > getting internet connectivity via ethernet over USB work. Someone MUST have

Re: [beagleboard] Trying to run the ADC from the PRU

The PRU hads to access the ADC through the L3_interconnect bus too . . . so the control register for the L3_interconnect must also be enabled. On Thu, Sep 15, 2016 at 2:27 PM, Phil <phil.s@gmail.com> wrote: > > > On Wednesday, September 7, 2016 at 10:36:02 AM UTC-5, William

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

in a device tree overlay. But I checked the source file for the eqep2b overlay, and all that seems to be in place. On Wed, Sep 14, 2016 at 7:35 PM, William Hermans <yyrk...@gmail.com> wrote: > Yeah that probably wont work. It's probably configuring the eQEP module as > a PWM. I don

Re: [beagleboard] Re: USB Disconnect/Reconnect Randomly

> > I have a BBB connected to Windows via USB. I'm watching the "Device > Manager" under Windows. The window constantly refreshes every 5 to 10 > seconds with the BBB Serial port showing and then... not showing. The > port is constantly reconnecting. It does this 90% of the time. There are >

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

> device export npwm power pwm0 subsystem uevent unexport > > debian@beaglebone:~$ ls /sys/class/pwm/pwmchip5/pwm0/ > duty_cycle enable period polarity power uevent > > > > > > On Wed, Sep 14, 2016 at 5:50 PM, William Hermans <yyrk...@gmail.com> > wrote: &g

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

0/ duty_cycle enable period polarity power uevent On Wed, Sep 14, 2016 at 5:50 PM, William Hermans <yyrk...@gmail.com> wrote: > *echo bone_eqep1 > $SLOTS* >> > -bash: echo: write error: File exists >> > > Yeah, you're going to get this error whenever you

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

> > *echo bone_eqep1 > $SLOTS* > -bash: echo: write error: File exists > Yeah, you're going to get this error whenever you load a device tree file that attempts to mux pins that have already been muxed in a different overlay. At minimum, when using config-pin overlay . I'm not however sure if one

Re: [beagleboard] Re: Remote Proc and examples to fill PRU data memory, store/read data in PRU shared memory

Hi Paul, I would advise against doing any "production" code using /dev/mem + mmap(). For the simple reason that you'll have latency introduced that will not be predictable. For your purposes. However, with that said, it would be ok for "test code" where timing is not too important. I would also

Re: [beagleboard] Re: Remote Proc and examples to fill PRU data memory, store/read data in PRU shared memory

form the ADC into memory, depending. On Tue, Sep 13, 2016 at 10:45 PM, William Hermans <yyrk...@gmail.com> wrote: > Perhaps this will also help ? > > http://processors.wiki.ti.com/index.php/AM335x_PRU_Read_Latencies > > On Tue, Sep 13, 2016 at 10:35 PM, William Hermans <yy

Re: [beagleboard] Re: Remote Proc and examples to fill PRU data memory, store/read data in PRU shared memory

Perhaps this will also help ? http://processors.wiki.ti.com/index.php/AM335x_PRU_Read_Latencies On Tue, Sep 13, 2016 at 10:35 PM, William Hermans <yyrk...@gmail.com> wrote: > From userland, and using /dev/mem + mmap() it is possible to get > ~3MB/second worth of samples from the o

Re: [beagleboard] Re: Remote Proc and examples to fill PRU data memory, store/read data in PRU shared memory

>From userland, and using /dev/mem + mmap() it is possible to get ~3MB/second worth of samples from the on die am335x processors ADC. Granted, many of these samples are redundant, but I wrote a C application to do this, *just* to see how much such an application could handle. Theoretically, the

Re: [beagleboard] how to change uEnv.txt from U boot interface ?

Fist, you would get an sdcard, and flash an image to it. http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#microSD.2FStandalone:_.28console.29_.28BeagleBone.2FBeagleBone_Black.2FBeagleBone_Green.29 Once you have that image on an sdcard, you boot as normal- with the sdcard inserted of course.

Re: [beagleboard] pinmux broken on hdmi pins in 4.4-ti kernel but working in 4.4-bone kernel

always read '0' whether that pin is pulled high, or low - externally. On Sat, Sep 10, 2016 at 8:55 PM, William Hermans <yyrk...@gmail.com> wrote: > Oh, and right. I'm still not clear on if SPI can be muxed outside of the > given board overlay file. While at the same time, it seems

Re: [beagleboard] Re: High speed encoder input capability of BBB?

There is an eCAP module in the processor that *perhaps* could be controlled via a PRU . . . but I have limited knowledge of that peripheral module, and no hands on . . . On Sat, Sep 10, 2016 at 6:25 PM, Dennis Lee Bieber wrote: > On Sat, 10 Sep 2016 15:04:23 -0700 (PDT),

Re: [beagleboard] pinmux broken on hdmi pins in 4.4-ti kernel but working in 4.4-bone kernel

:45 PM, William Hermans <yyrk...@gmail.com> wrote: > Is this a reason we can't get it working in both? >> > > Are you speaking to me Jason ? > > If so I'm not sure what the problem the OP is having. But I can say that > "we" do not need to to any extra pin muxi

Re: [beagleboard] pinmux broken on hdmi pins in 4.4-ti kernel but working in 4.4-bone kernel

n Sat, Sep 10, 2016 at 3:00 PM, Jason Kridner <jkrid...@gmail.com> wrote: > Is this a reason we can't get it working in both? > > On Sep 10, 2016, at 2:11 PM, William Hermans <yyrk...@gmail.com> wrote: > > Sure, the work around is don't use those kernels. > > will

Re: [beagleboard] pinmux broken on hdmi pins in 4.4-ti kernel but working in 4.4-bone kernel

Sure, the work around is don't use those kernels. william@beaglebone:~$ uname -r 4.4.14-ti-r34 william@beaglebone:~$ ls /sys/class/gpio export gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport william@beaglebone:~$ sudo sh -c "echo '115' > /sys/class/gpio/export" [sudo] password for

Re: [beagleboard] Re: Header files for non PRU peripherals

(GPIO_CLEARDATAOUT) address. Ok thats confusing . . .but I guess I read this and understood the opposite of what it's saying ? e.g. I was thinking DATAOUT would be fast ? On Thu, Sep 8, 2016 at 1:56 PM, William Hermans <yyrk...@gmail.com> wrote: > Oh...while we're on the subject, there's

Re: [beagleboard] Re: Header files for non PRU peripherals

the TRM. TO me it seems that the SETDATA(direction) registers actually write to DATAOUT. did I read that wrong ? On Thu, Sep 8, 2016 at 1:51 PM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > On 9/8/2016 3:35 PM, Charles Steinkuehler wrote: > > On 9/8/2016 12:41 PM, William H

Re: [beagleboard] gpio1_16 and gpio2_0 issues on beaglebone green.

in order for this 1 pin to be usable ? On Wed, Sep 7, 2016 at 8:35 PM, William Hermans <yyrk...@gmail.com> wrote: > So, I still do not know what exactly the problem *is*. So for those of you > who need to use this pin, I guess you, and everyone else who is using a 4.x > kernel will have t

Re: [beagleboard] Re: Header files for non PRU peripherals

On Thu, Sep 8, 2016 at 6:36 AM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > On 9/7/2016 7:50 PM, William Hermans wrote: > > > > SETDATAOUT -> |= BITx > > CLEARDATAOUT -> &=(~BITx) > > > > I gues I'll have to reread the TRM again.

Re: [beagleboard] gpio1_16 and gpio2_0 issues on beaglebone green.

, 2016 at 6:09 PM, William Hermans <yyrk...@gmail.com> wrote: > Let me rephrase that. The board seems to boot and come up, but I was > unable to ssh into the board. For whatever reason. Did not care to look why. > > On Wed, Sep 7, 2016 at 6:08 PM, William Hermans <yyrk...@gmai

Re: [beagleboard] gpio1_16 and gpio2_0 issues on beaglebone green.

Let me rephrase that. The board seems to boot and come up, but I was unable to ssh into the board. For whatever reason. Did not care to look why. On Wed, Sep 7, 2016 at 6:08 PM, William Hermans <yyrk...@gmail.com> wrote: > So, booting and loading am335x-bonegreen-overlay.dtb on a b

Re: [beagleboard] gpio1_16 and gpio2_0 issues on beaglebone green.

So, booting and loading am335x-bonegreen-overlay.dtb on a beaglebone green will render the board unbootable. On Wed, Sep 7, 2016 at 5:24 PM, William Hermans <yyrk...@gmail.com> wrote: > Just for clarity > > *debian@beaglebone:~$* sudo sh -c "echo '1' > > /sys/class/gp

Re: [beagleboard] Re: Header files for non PRU peripherals

On Wed, Sep 7, 2016 at 5:39 PM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > On 9/7/2016 5:18 PM, William Hermans wrote: > > > > I agree with Charles with one exception. I personally prefer to use > DATAOUT > > directly instead of using SETDATAOUT /

Re: [beagleboard] gpio1_16 and gpio2_0 issues on beaglebone green.

io/gpio48/value 1 So, I'm not experiencing an "off by 1" issue. But for some reason gpio1_16 *only* works if a universal IO overlay that deals with gpio1_16 appropriately - *somehow*. I'm not sure what I'm missing. Is this a software bug of some sort ? On Wed, Sep 7, 2016 at 4:39 PM, Willi

Re: [beagleboard] gpio1_16 and gpio2_0 issues on beaglebone green.

t4_txd_mux2 */ BONE_P9_15 (PIN_INPUT | MUX_MODE7) /* gpmc_a0.gpio1[16] */ *0x088 (PIN_INPUT | MUX_MODE7) /* gpmc_csn3.gpio2[0] */* >; }; That should be the culprit, but do I realy need to create a seperate custom board file just for this purpose ? Seem

Re: [beagleboard] Re: Header files for non PRU peripherals

On Wed, Sep 7, 2016 at 2:28 PM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > > IMHO it works best if you setup the GPIO banks with Linux, then use > the PRU to twiddle the output bits using the set and clear registers > in the GPIO bank. That way you don't have to worry about any

Re: [beagleboard] gpio1_16 and gpio2_0 issues on beaglebone green.

without universal io, config pin, or any of that. On Wed, Sep 7, 2016 at 2:00 PM, William Hermans <yyrk...@gmail.com> wrote: > Additionally, using: > > $ sudo config-pin overlay univ-all > $ sudo config-pin P9.15 hi / low > > Seems to work fine on the BBG too. However

Re: [beagleboard] gpio1_16 and gpio2_0 issues on beaglebone green.

, William Hermans <yyrk...@gmail.com> wrote: > So as the subject says we're having issues with gpio1_16 and gpio2_0 being > tied together through r161. We've removed r161 on one beaglebone green, > then export gpio48(gpio1_16) through sysfs, set the direction to 'in', in > an att

[beagleboard] gpio1_16 and gpio2_0 issues on beaglebone green.

So as the subject says we're having issues with gpio1_16 and gpio2_0 being tied together through r161. We've removed r161 on one beaglebone green, then export gpio48(gpio1_16) through sysfs, set the direction to 'in', in an attempt to read input to an externally connected sensor. This does not

Re: [beagleboard] Trying to run the ADC from the PRU

The only thing I can think of is that you're not enabling the ADC control register. Below is a code snippet from another post. //Init ADC CTRL register MOV r2, 0x44E0D040 MOV r3, 0x0005 SBBO r3, r2, 0, 4 >From this post:

Re: [beagleboard] analogRead in bonescript fails on first attempt after reboot

not have the time. . . On Mon, Sep 5, 2016 at 2:03 PM, William Hermans <yyrk...@gmail.com> wrote: > Yeah it sound like bonescript, or the newer refactored version may not > correctly handle the "file does not exist" exception correctly. As it > currently sits. > > I

Re: [beagleboard] analogRead in bonescript fails on first attempt after reboot

Yeah it sound like bonescript, or the newer refactored version may not correctly handle the "file does not exist" exception correctly. As it currently sits. Ideally, in code you would check that the file you're about to use exists, and if it does not then you load the appropriate device tree

Re: [beagleboard] BBG - Soft poweroff does not work

If by chance that does not work for you. Use the latest image. Jessie 8.5 I believe. It works, or at least works for me, with the beaglebone black or beaglebone green. On Mon, Sep 5, 2016 at 8:49 AM, William Hermans <yyrk...@gmail.com> wrote: > $ sudo apt-get install acpid > > Gi

Re: [beagleboard] BBG - Soft poweroff does not work

$ sudo apt-get install acpid Give that a whirl, it should fix your issue. You changed images didnt you ? from LXDE image to one of the command line images. Right ? On Mon, Sep 5, 2016 at 7:08 AM, Steven Hirsch wrote: > Title says it. After updating to Debian 8.4 I find

Re: [beagleboard] BBB battery charging

regulator/ > tps65217-regulator.c?v=4.4 > The low-level driver you have looked at is used by this. > > Cheers > Christoph > > On Sat, Sep 3, 2016 at 4:04 AM, William Hermans <yyrk...@gmail.com> wrote: > > So I did some searching on this because I am interested in this as we

Re: [beagleboard] BBB battery charging

interestingly: *william@beaglebone:~$ cat* /sys/bus/i2c/drivers/tps65217/0-0024/tps65217-charger/power/runtime_enabled disabled So is it possible to change this to "enabled" ? If so what are the consequences ? On Fri, Sep 2, 2016 at 7:04 PM, William Hermans <yyrk...@gmail.com>

Re: [beagleboard] BBB battery charging

uot;twiddle" the register bits. I would have to experiment with this myself to confirm that anything I think may be possible. Actually *is* possible. On Fri, Sep 2, 2016 at 3:52 PM, William Hermans <yyrk...@gmail.com> wrote: > Page 41 of the datasheet, looks like registers 3-6. Alt

Re: [beagleboard] BBB battery charging

Page 41 of the datasheet, looks like registers 3-6. Although I have not read in details what the function of those registers are. This should be fixable through custom software, but I'd have to read in greater detail to understand what must be done, and what should be checked for before manually

Re: [beagleboard] Can't upgrade my Beaglebone Black's kernel from 3.8 to 4.* version

> > Thanks for your answer, Robert. I checked option, but I don't have a > microSD card right now. Is there a way to install images without using an > SD card or SD card is the only option? > No, not really. Well actually you *could* "boot" off USB, but this should really be done with the

Re: [beagleboard] 4.1 or 4.4 kernel for best stability and feature support on BBB

el versions. And if that > fails, I'll switch to a new image per Robert's suggestion. > > Thanks, > Alex > > On Thursday, August 25, 2016 at 8:41:58 PM UTC-4, William Hermans wrote: >> >> Alexander, >> >> Are you just loading the rootfs and kernel from USB ?

Re: [beagleboard] 4.1 or 4.4 kernel for best stability and feature support on BBB

Alexander, Are you just loading the rootfs and kernel from USB ? If this is the case you should not need a custom first or second stage bootloader. Granted I have not done this myself since 3.8.x kernels, but It should just work, Unless uboot has changed in this regard. Don't see why it should

Re: [beagleboard] USB Connection kills laptops WIFI

This, which I'm assuming if your wifi adapter ? wlo1 Link encap:Ethernet HWaddr 2c:33:7a:80:90:79 *inet addr:10.67.66.49 Bcast:10.67.79.255 Mask:255.255.240.0* inet6 addr: fe80::5bed:8318:765b:bc41/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500

Re: [beagleboard] Re: Monodevelop running terminal commands

Heres a quick simple example of command specific sudo usage. http://www.atrixnet.com/allow-an-unprivileged-user-to-run-a-certain-command-with-sudo/ On Mon, Aug 22, 2016 at 11:17 AM, William Hermans <yyrk...@gmail.com> wrote: > I'd probably consider using groups. Like I briefly dis

<    3   4   5   6   7   8   9   10   11   12   >