Re: [beagleboard] Re: PRU Pin Mux

2014-06-21 Thread Brandon I
You have 100% full control over anything the PRU can access. This pru code seems to disproves this. The PRU cannot modify the configuration registers. // enable ocp master. LBCO r0, C4, 4, 4 CLR r0, r0, 4 SBCO r0, C4, 4, 4 // turn on gpio mov r1, 0x4000 mov r0, 0x44E07194 SBBO b, a, 0, 4 //

Re: [beagleboard] Re: PRU Pin Mux

2014-06-21 Thread Brandon I
I apologize, a miss click posted that...full code below. *// enable ocp master.*LBCO r0, C4, 4, 4 CLR r0, r0, 4 SBCO r0, C4, 4, 4 *// try to set gpio address* *// gpio on*mov r1, 0x4000# gpio 0, bit 14, p9.29 mov r0, 0x44E07194 # gpio 0 set register SBBO r1, r0, 0, 4 *//

Re: [beagleboard] Setting volume from C++ on the audio cape (Rev B1)

2014-06-21 Thread John Syn
From: Charles Kerr charlesker...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Friday, June 20, 2014 at 6:36 PM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: [beagleboard] Setting volume from C++ on the audio cape (Rev B1) I

Re: [beagleboard] Re: BBB PRU input test

2014-06-21 Thread Manuel Berro Madero
Why 0b1? On 06/21/2014 01:40 AM, TJF wrote: Am Samstag, 21. Juni 2014 01:37:20 UTC+2 schrieb Manu: I need to read the bit r31.t16 and capture the current state either 1 or 0 and set it to r3 Try AND r3, r31.b2, 0b1 -- For more options, visit http://beagleboard.org/discuss ---

Re: [beagleboard] Re: BBB PRU input test

2014-06-21 Thread Charles Steinkuehler
0b1 is the bitmask (in binary), the same as 0x01 in the shift and mask code I sent. Since the bit you want is already in the least significant location in a byte, you don't really have to shift it first. You can do the move and mask with a single AND instruction. On 6/21/2014 7:57 AM, Manuel

[beagleboard] Re: 8192.ko Module Format Error on Debian

2014-06-21 Thread Sibi Sankar
It's awesome that you got it to work .I tried to do the same to rtl8192eu and sadly the patch by cmicali does not work. Is there any chance to get it to work.Or should I ask cmicali for instructions on patching.Thank you. -- For more options, visit http://beagleboard.org/discuss --- You

Re: [beagleboard] Re: PRU Pin Mux

2014-06-21 Thread TJF
A miss click and a miss post ... The PRUSS can access the Control Modul pin mux registers. It's working for a lot of libpruio users. Did you enable the OCP master port? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the

[beagleboard] Fun with Chromium OS

2014-06-21 Thread Joey Carlini
After a bit of searching around, it turns out there is a port of Chromium OS for Beaglebone ready to go, but used as internal testing at Google for new hardware and junk. Could we combine this with the generic-arm overlay to have a fully functional version of Chromium OS for the Black?

[beagleboard] Can't saveenv

2014-06-21 Thread Lucas Tanure
I can't saveenv. I got this: U-Boot# saveenv Saving Environment to NAND... Erasing NAND... Attempt to erase non block-aligned data -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To

[beagleboard] Device Tree Overlay pinmux modification doe not modify the physical pin or the file interface values

2014-06-21 Thread Michael M
The changes I make to the pinmux in the Device Tree Overlay are not reflected when I read the files in /sys/class/gpio or probe the physical pin itself. However, the change IS reflected when I read /sys/kernel/debug/pinctrl/44e10800.pinmux/pins. The OS is the Rev C Debian build. Setting the

Re: [beagleboard] Can't saveenv

2014-06-21 Thread David Lambert
I am not an expert in this, but if this is a Beaglebone, I don't think there is any NAND, so saveenv will not work. I think modifications to environment go in uEnv.txt or must be compiled into U-Boot. HTH, Dave. On 06/21/2014 07:51 PM, Lucas Tanure wrote: I can't saveenv. I got this:

[beagleboard] Re: Device Tree Overlay pinmux modification doe not modify the physical pin or the file interface values

2014-06-21 Thread serge . nsk14
Hi Michael When I do 'cat value' in the gpio48 directory, I get 1. I should get a 0 since the pulldown is enabled. To my experience the 'cat value' not always reflects actual level on the wire. and Should modifications in the DTO reflect in the file interfaces and on the physical pin