[beagleboard] access to sf probe

[irappahukkeri]

when i type sf probe 2 for initialize it is giving like this-->"SF: 
Unsupported flash IDs: manuf 00, jedec , ext_jedec 
Failed to initialize SPI flash at 0:0"
let me know how to check whether sf interface in presented or not 
please help me how i can get uboot through accessing the sf probe

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

[beagleboard] USB Hub freeze

[Guido Paoluzi Cusani]

My communication link:
BBB USB <-> USB2514B based USB hub <-> FTDI FT232
Abruptly fails for no evident reason (possibly EMI or other induced 
noise... there is a vast evidence ( better say a lot of rumors ) of the BBB 
USB being very sensitive all over the web).
uname -r output:
4.1.10-ti-r21 
dmesg output:  
[ 4951.213705] usb 1-1.1: USB disconnect, device number 3
[ 4951.215742] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now 
disconnected from ttyUSB0
[ 4951.216492] ftdi_sio 1-1.1:1.0: device disconnected
[ 4951.458827] usb 1-1.1: new full-speed USB device number 5 using musb-hdrc
[ 4951.538810] usb 1-1.1: device descriptor read/64, error -32
[ 4951.728815] usb 1-1.1: device descriptor read/64, error -32
[ 4951.918801] usb 1-1.1: new full-speed USB device number 6 using musb-hdrc
[ 4951.998947] usb 1-1.1: device descriptor read/64, error -32
[ 4952.188807] usb 1-1.1: device descriptor read/64, error -32
[ 4952.378887] usb 1-1.1: new full-speed USB device number 7 using musb-hdrc
[ 4952.798847] usb 1-1.1: device not accepting address 7, error -32
[ 4952.898825] usb 1-1.1: new full-speed USB device number 8 using musb-hdrc
[ 4953.318766] usb 1-1.1: device not accepting address 8, error -32
[ 4953.325078] usb 1-1-port1: unable to enumerate USB device 
the link doesn't recover unless the hub goes through a hardware reset or a 
power OFF\ON cycle; 
The hub appears to go in "Suspended Mode" when the problem arises.
I am wondering:
there is a Sitara Linux MUSB Issue with the USB_RESUME in AMSDK 
08.00.00.00: is the kernel 4.1.10-ti-r21 incorporating the workaround?
Any way I can software reset the hub from Linux?
Any hint on what is happening?
Thanks in advance for any help on this.

Guido
 



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

[beagleboard] alsa configuration

[fannylarradet]

hello, 
i have a beagleblack bone device and i have two different cards, one for 
play sound and one for record , the one for recording is usb when the 
otherone is pluged in the BBB. 
I'm trying to figured out what configuration file to have. For now i have :

pcm.usb
{
type hw
card 1
device 0
}

pcm.internal
{
type hw
card 0
device 0
}

pcm.!default
{
type asym
playback.pcm
{
type plug
slave.pcm "internal"
}
capture.pcm
{
type plug
slave.pcm "usb"
}
}

ctl.!default
{
type asym
playback.pcm
{
type plug
slave.pcm "internal"
}
capture.pcm
{
type plug
slave.pcm "usb"
}
}

but it is not working. If I reload alsa then i cannot open alsamixer 
anymore( alsamixer work fine if i delete the configuration file ) : 


ALSA lib dlmisc.c:254:(snd1_dlobj_cache_get) Cannot open shared library 
/usr/lib/arm-linux-gnueabihf/alsa-lib/libasound_module_ctl_asym.so
cannot open mixer: No such device or address


and i cannot play sound : 


aplay /usr/share/sounds/alsa/Front_Center.wav
aplay: main:682: audio open error: Device or resource busy


configuration: 

debian weezy 


cat /proc/asound/pcm
00-00: AIC3X tlv320aic3x-hifi-0 :  : playback 1 : capture 1
01-00: USB Audio : USB Audio : capture 1

please help 
thanks

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

Re: [beagleboard] HDMI License

[mebbyeng]

Thank you very much, Gerald.
It was very helpful.


2015年10月19日月曜日 22時41分53秒 UTC+9 Gerald:
>
> Encryption is not supported. We use an HDMI framer but we are not HDMI 
> certified. So unless you want the HDMI logo, there is no need for a license.
>
> If you want the Logo then you need to get it certified and you must 
> replace the framer with the more expensive version of the framer that 
> supports the encryption.
>
> Gerald
>
>
> On Mon, Oct 19, 2015 at 1:50 AM,  wrote:
>
>> hi
>>
>> If we sold incorporating the BBB in our product, 
>> do we have to pay the HDMI of royalty?
>>
>> We do not use the HDMI logo.
>>
>> We asked TI about this question, but they were introduced here.
>> Please tell me if you know.
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/
>

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

[beagleboard] to access beaglebone black interface using uboot commands

[irappahukkeri]

I want to know about beaglebone black for read and write the ddr3,nand,i2c 
etc..
so please could you help me steps through using the uboot 

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

[beagleboard] Assembly help with beaglebone. Undefined symbol.

[javaid . salman]

I have a pretty simple program below 

void foo()
{
int r5 = 0;
int a = 0;
asm
(
"mov r5, $4\n\t"
"add r5, a"
);
}

void main (void)
{
foo();
}

When I compile it, I get:

/tmp/ccM76e6z.s: Assembler messages:
/tmp/ccM76e6z.s:36: Error: undefined symbol a used as an immediate value


My gcc version:

gcc (Debian 4.6.3-14) 4.6.3






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

Re: [beagleboard] OSX el Capitan breaks HoRNDIS?

[Robert Nelson]

On Tue, Oct 20, 2015 at 10:13 AM, Robert Nelson  wrote:
> On Tue, Oct 20, 2015 at 10:03 AM, William Nickell  
> wrote:
>> According to this: http://www.joshuawise.com/horndis el Capitan breaks the
>> HoRNDIS program.
>>
>> I just started trying to connect to the BBB. Network preferences does not
>> find the BBB.
>>
>> Anyone got suggestions?
>
> read the bug:
>
> https://github.com/jwise/HoRNDIS/issues/42
>
> Looks like progress towards the end..

http://nyus.joshuawise.com/HoRNDIS-rel8pre1.pkg

Regards,

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

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

Re: [beagleboard] OSX el Capitan breaks HoRNDIS?

[Robert Nelson]

On Tue, Oct 20, 2015 at 10:03 AM, William Nickell  wrote:
> According to this: http://www.joshuawise.com/horndis el Capitan breaks the
> HoRNDIS program.
>
> I just started trying to connect to the BBB. Network preferences does not
> find the BBB.
>
> Anyone got suggestions?

read the bug:

https://github.com/jwise/HoRNDIS/issues/42

Looks like progress towards the end..

Regards,

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

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

Re: [beagleboard] BeagleBone Green Grove i2c issues

[Jason Kridner]

On Mon, Oct 19, 2015 at 10:11 PM, Ben Shapiro  wrote:
> Ok... so I've banged my head about this more and, have made some progress.
> THANK YOU for your help thus far.
>
> Still, this are really broken. As an example, the instructions here to blink
> an LED don't work. They don't crash, but nothing happens on the board when I
> run them. Suggestions?

It is difficult to check your work using the GUI (ie., clicking the
right button). Can you get to the command prompt (right there in
Cloud9 IDE) and do the following and capture the entire terminal
session and paste here?

# cat yourfile.py
# python yourfile.py

>
> On the bright side: Some grove devices now show up in i2cdetect. There are
> others that don't. And I can't figure out how to get the non i2c port to
> work as gpio (for example the LED example linked to above).

Are you doing 'i2cdetect -y 2' ?

Depending on the kernel, you might be able to use 'config-pin'

>
> Have any of you actually gotten a BBG working with common grove sensors? For
> example, the Digital Temp and Humidity sensor (I have the "pro" and the
> non-pro versions)? Some example code would be really helpful.

I have. The code shipped with the board worked for me. I'm in process
of pushing it into the bone101 code.

>
>
>
>
> On Monday, October 19, 2015 at 7:31:34 PM UTC-6, Ben Shapiro wrote:
>>
>> I get this "reference is not a tree" error when following William's
>> instructions.
>> Commenting out the code that tries to use that sha seems to fix the
>> problem.
>>
>>
>> On Monday, October 19, 2015 at 1:10:27 PM UTC-6, William Hermans wrote:
>>>
>>> @Robert
>>>
>>> By the way Robert . . .
>>>
>>> debian@beaglebone:~/bb.org-overlays$ ./dtc-overlay.sh
>>>  CLEAN (libfdt)
>>>  CLEAN (tests)
>>>  CLEAN
>>> Already on 'master'
>>> Already up-to-date.
>>> fatal: reference is not a tree: f6dbc6ca9618391e4f30c415a0a09b7af35f7647
>>>
>>> Kind of has me stuck . . . heh probably a bad idea for me to test
>>> downgrade dtc . . .
>>>
>>> On Mon, Oct 19, 2015 at 11:59 AM, William Hermans 
>>> wrote:

 Ok, so you have no device tree files. First things first. I'm using a
 4.1.x kernel so your output should be slightly different.

 debian@beaglebone:~$ which dtc
 /usr/local/bin/dtc
 debian@beaglebone:~$ dtc --version
 Version: DTC 1.4.1-ge733c7b8

 You version should be something like 1.4.0-. If dtc is not installed
 . . .

 wget -c
 https://raw.githubusercontent.com/RobertCNelson/tools/master/pkgs/dtc.sh
 chmod +x dtc.sh
 ./dtc.sh

 debian@beaglebone:~$ dtc -v
 Version: DTC 1.4.0-gf345d9e4

 Then, Setup and compile dtbo's . . .

 $ sudo apt-get install git
 $ git clone https://github.com/beagleboard/bb.org-overlays
 $ cd bb.org-overlays/
 $ ./dtc-overlay.sh

 Install dtbo's
 $ sudo ./install.sh


 Check /lib/firmware/:
 $ ls /lib/firmware/

 Let me know if you have any problems with that.

 On Mon, Oct 19, 2015 at 9:57 AM, Ben Shapiro 
 wrote:
>
> So… I installed the image that Robert pointed me to. And things still
> aren’t working. Here’s some more info.
>
>
> root@beaglebone:/lib/firmware# ls /lib/firmware/
> dra7-ipu2-fw.xem4  dra7xx-m4-ipu2.xem4 vpdma-1b8.bin
>
> None of them mention i2c in the name (as William Hermans message
> suggested one should).
>
> However, this is as one would expect:
> root@beaglebone:/lib/firmware# ls /boot/dtbs/`uname -r` |grep green
> am335x-bonegreen-overlay.dtb
> am335x-bonegreen.dtb
>
> Output from i2cdetect is identical with before.
>
> Other suggestions?
>
> Ben
>
>
> On Oct 18, 2015, at 2:51 PM, William Hermans  wrote:
>
>>
>> Hi William,
>>
>> Thanks for writing back. I haven't resolved it, no.
>> I can't find any info about the proper device tree in the BBG
>> documentation. Do you know where I could find one that includes the grove
>> connector busses?
>>
>> Ben
>
>
> Well, not exactly but . . . First, you need to be aware that every
> board, be it Beaglebone black, white, or green all have their own initial
> device tree file which is board specific that gets loaded at boot time.
>
> So if you looks at the /boot/dtbs/`uname -r` . . .
>
> $ ls /boot/dtbs/`uname -r` |grep green
> am335x-bonegreen.dtb
>
> You should get the same output from the above command. Ok so here I
> have to assume once your board has this file loaded at boot. Your board,
> should effectively behave like any other Beagelbone. With this in mind if 
> we
> look at /lib/firmware/ . . .
>
> $ ls /lib/firmware/ | grep I2C
> BB-I2C1-00A0.dtbo
> BB-I2C1-PCA9685-00A0.dtbo
>
> Looks like, at least for me, I have 

[beagleboard] OSX el Capitan breaks HoRNDIS?

[William Nickell]

According to this: http://www.joshuawise.com/horndis el Capitan breaks the 
HoRNDIS program.

I just started trying to connect to the BBB. Network preferences does not 
find the BBB.

Anyone got suggestions?

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

Re: [beagleboard] BeagleBone Green Grove i2c issues

[Ben Shapiro]

Jason,

Thanks for trying to help. See below.

Ben

On Oct 20, 2015, at 2:01 PM, Jason Kridner 
> wrote:

On Mon, Oct 19, 2015 at 10:11 PM, Ben Shapiro 
> wrote:
Ok... so I've banged my head about this more and, have made some progress.
THANK YOU for your help thus far.

Still, this are really broken. As an example, the instructions here to blink
an LED don't work. They don't crash, but nothing happens on the board when I
run them. Suggestions?

It is difficult to check your work using the GUI (ie., clicking the
right button). Can you get to the command prompt (right there in
Cloud9 IDE) and do the following and capture the entire terminal
session and paste here?

# cat yourfile.py
# python yourfile.py


I’ve never used Cloud9 and have done everything from within SSH.

In any case, here’s the file:

debian@bonehog:~/making_bbg_work$ cat blink.py
import Adafruit_BBIO.GPIO as GPIO
import time
GPIO.setup("P9_14", GPIO.OUT)
while True:
GPIO.output("P9_14", GPIO.HIGH)
time.sleep(0.5)
GPIO.output("P9_14", GPIO.LOW)
time.sleep(0.5)

Running the script produces no output, either on the console or in the behavior 
of any of the LEDs.


On the bright side: Some grove devices now show up in i2cdetect. There are
others that don't. And I can't figure out how to get the non i2c port to
work as gpio (for example the LED example linked to above).

Are you doing 'i2cdetect -y 2’ ?

Yes. The Grove RGB LCD shows up. And I can even issue commands to activate and 
change the backlight color. But I can’t get any text to appear.


Depending on the kernel, you might be able to use 'config-pin’


I don’t know what config-pin is. And no file by that name exists on my device.


Have any of you actually gotten a BBG working with common grove sensors? For
example, the Digital Temp and Humidity sensor (I have the "pro" and the
non-pro versions)? Some example code would be really helpful.

I have. The code shipped with the board worked for me. I'm in process
of pushing it into the bone101 code.


Code shipped with the board??? Does it exist online somewhere?





On Monday, October 19, 2015 at 7:31:34 PM UTC-6, Ben Shapiro wrote:

I get this "reference is not a tree" error when following William's
instructions.
Commenting out the code that tries to use that sha seems to fix the
problem.


On Monday, October 19, 2015 at 1:10:27 PM UTC-6, William Hermans wrote:

@Robert

By the way Robert . . .

debian@beaglebone:~/bb.org-overlays$ ./dtc-overlay.sh
CLEAN (libfdt)
CLEAN (tests)
CLEAN
Already on 'master'
Already up-to-date.
fatal: reference is not a tree: f6dbc6ca9618391e4f30c415a0a09b7af35f7647

Kind of has me stuck . . . heh probably a bad idea for me to test
downgrade dtc . . .

On Mon, Oct 19, 2015 at 11:59 AM, William Hermans 
>
wrote:

Ok, so you have no device tree files. First things first. I'm using a
4.1.x kernel so your output should be slightly different.

debian@beaglebone:~$ which dtc
/usr/local/bin/dtc
debian@beaglebone:~$ dtc --version
Version: DTC 1.4.1-ge733c7b8

You version should be something like 1.4.0-. If dtc is not installed
. . .

wget -c
https://raw.githubusercontent.com/RobertCNelson/tools/master/pkgs/dtc.sh
chmod +x dtc.sh
./dtc.sh

debian@beaglebone:~$ dtc -v
Version: DTC 1.4.0-gf345d9e4

Then, Setup and compile dtbo's . . .

$ sudo apt-get install git
$ git clone https://github.com/beagleboard/bb.org-overlays
$ cd bb.org-overlays/
$ ./dtc-overlay.sh

Install dtbo's
$ sudo ./install.sh


Check /lib/firmware/:
$ ls /lib/firmware/

Let me know if you have any problems with that.

On Mon, Oct 19, 2015 at 9:57 AM, Ben Shapiro 
wrote:

So… I installed the image that Robert pointed me to. And things still
aren’t working. Here’s some more info.


root@beaglebone:/lib/firmware# ls /lib/firmware/
dra7-ipu2-fw.xem4  dra7xx-m4-ipu2.xem4 vpdma-1b8.bin

None of them mention i2c in the name (as William Hermans message
suggested one should).

However, this is as one would expect:
root@beaglebone:/lib/firmware# ls /boot/dtbs/`uname -r` |grep green
am335x-bonegreen-overlay.dtb
am335x-bonegreen.dtb

Output from i2cdetect is identical with before.

Other suggestions?

Ben


On Oct 18, 2015, at 2:51 PM, William Hermans  wrote:


Hi William,

Thanks for writing back. I haven't resolved it, no.
I can't find any info about the proper device tree in the BBG
documentation. Do you know where I could find one that includes the grove
connector busses?

Ben


Well, not exactly but . . . First, you need to be aware that every
board, be it Beaglebone black, white, or green all have their own initial
device tree file which is board specific that gets loaded at boot time.

So if you looks at the /boot/dtbs/`uname -r` . . .

$ ls /boot/dtbs/`uname -r` |grep green
am335x-bonegreen.dtb

You should 

Re: [beagleboard] How could I compile a hello.ko that can run on my BBB?

[Mian Tang]

I reply myself. It's fixed.

And now, I plan to switch to kernel 4.1.1. It seems that 3.8.13 is an 
old version and will be replaced sooner or later...

On Saturday, October 17, 2015 at 10:44:29 PM UTC-4, Mian Tang wrote:
>
> I downloaded the bb-kernel-3.8.13-bone79, and hello sample driver to my PC.
>
> Compiled it without problem. When using modinfo to see hello.ko, it 
> displays:
>
> filename:   hello.ko
> version:0.1
> description:A simple Linux driver for the BBB.
> author: Derek Molloy
> license:GPL
> srcversion: 0DD9FE0DE42157F9221E608
> depends:
> vermagic:   3.8.13+ SMP mod_unload modversions ARMv7 thumb2 p2v8 
> parm:   name:The name to display in /var/log/kern.log (charp)
>
>
> The "vermagic" is "3.8.13+ SMP.", it should be 3.8.13-bone79, right?
>
>
> Best Regards,
> Mian
>
>
>
>
>
> On Friday, October 16, 2015 at 6:09:50 PM UTC-4, Mian Tang wrote:
>>
>> OK. This is the error:
>>
>> root@beaglebone:~# insmod hello.ko
>> Error: could not insert module hello.ko: Invalid module format
>>
>> And I checked the current version below:
>>
>> root@beaglebone:~# uname -r
>> 3.8.13-bone79
>>
>> Could you please tell me where I can get the kernel source which has the 
>> same version as my BBB board?
>>
>>
>>
>> On Friday, October 16, 2015 at 5:39:09 PM UTC-4, Przemek Klosowski wrote:
>>>
>>>
>>>
>>> On Fri, Oct 16, 2015 at 2:53 PM, Mian Tang  wrote:
>>>
 Hi,

 I connect my BBB to internet do update. When I use "uname -r" to check 
 the version, it displays: 3.8.13-bone79.

 Now, I hope to compile a hello.ko module driver on PC and run it on the 
 board.

>>> You seem to have a test kernel module that you want to compile and 
>>> insert into a running kernel. Normally, you'd just 'make hello.ko' and 
>>> 'insmod hello.ko'. This wouldn't work if the kernel API used by the module 
>>> was so different that it wouldn't work with the header files used by your 
>>> current kernel (btw. for this to work, your system has to have kernel 
>>> development packages installed).
>>> Try this and report if you encounter errors--it'll be much easier to 
>>> help if you say in detail what you did and what happened as a result.
>>>
>>

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

Re: [beagleboard] BeagleBone Green Grove i2c issues

[Jason Kridner]

> On Oct 20, 2015, at 7:50 PM, Ben Shapiro  wrote:
> 
> Jason, 
> 
> Thanks for trying to help. See below.
> 
> Ben
> 
>> On Oct 20, 2015, at 2:01 PM, Jason Kridner  wrote:
>> 
>> On Mon, Oct 19, 2015 at 10:11 PM, Ben Shapiro  
>> wrote:
>>> Ok... so I've banged my head about this more and, have made some progress.
>>> THANK YOU for your help thus far.
>>> 
>>> Still, this are really broken. As an example, the instructions here to blink
>>> an LED don't work. They don't crash, but nothing happens on the board when I
>>> run them. Suggestions?
>> 
>> It is difficult to check your work using the GUI (ie., clicking the
>> right button). Can you get to the command prompt (right there in
>> Cloud9 IDE) and do the following and capture the entire terminal
>> session and paste here?
>> 
>> # cat yourfile.py
>> # python yourfile.py
> 
> I’ve never used Cloud9 and have done everything from within SSH. 
> 
> In any case, here’s the file:
> 
> debian@bonehog:~/making_bbg_work$ cat blink.py
> import Adafruit_BBIO.GPIO as GPIO
> import time
> GPIO.setup("P9_14", GPIO.OUT)
> while True:
> GPIO.output("P9_14", GPIO.HIGH)
> time.sleep(0.5)
> GPIO.output("P9_14", GPIO.LOW)
> time.sleep(0.5)
> 
> Running the script produces no output, either on the console or in the 
> behavior of any of the LEDs.

P9_14 is a pin, not one of the built-in LEDs. I'll ping them to make that 
clearer. 

> 
>>> 
>>> On the bright side: Some grove devices now show up in i2cdetect. There are
>>> others that don't. And I can't figure out how to get the non i2c port to
>>> work as gpio (for example the LED example linked to above).
>> 
>> Are you doing 'i2cdetect -y 2’ ?
> 
> Yes. The Grove RGB LCD shows up. And I can even issue commands to activate 
> and change the backlight color. But I can’t get any text to appear. 

I had a similar challenge, but I think if I2C works, it must be something with 
the commands themselves. Have you checked out the Python examples? I will check 
it out myself tomorrow. 

> 
>> 
>> Depending on the kernel, you might be able to use 'config-pin’
> 
> I don’t know what config-pin is. And no file by that name exists on my device.
> 
>>> 
>>> Have any of you actually gotten a BBG working with common grove sensors? For
>>> example, the Digital Temp and Humidity sensor (I have the "pro" and the
>>> non-pro versions)? Some example code would be really helpful.
>> 
>> I have. The code shipped with the board worked for me. I'm in process
>> of pushing it into the bone101 code.
> 
> Code shipped with the board??? Does it exist online somewhere?
> 
>>> 
>>> 
>>> 
>>> 
 On Monday, October 19, 2015 at 7:31:34 PM UTC-6, Ben Shapiro wrote:
 
 I get this "reference is not a tree" error when following William's
 instructions.
 Commenting out the code that tries to use that sha seems to fix the
 problem.
 
 
> On Monday, October 19, 2015 at 1:10:27 PM UTC-6, William Hermans wrote:
> 
> @Robert
> 
> By the way Robert . . .
> 
> debian@beaglebone:~/bb.org-overlays$ ./dtc-overlay.sh
> CLEAN (libfdt)
> CLEAN (tests)
> CLEAN
> Already on 'master'
> Already up-to-date.
> fatal: reference is not a tree: f6dbc6ca9618391e4f30c415a0a09b7af35f7647
> 
> Kind of has me stuck . . . heh probably a bad idea for me to test
> downgrade dtc . . .
> 
> On Mon, Oct 19, 2015 at 11:59 AM, William Hermans 
> wrote:
>> 
>> Ok, so you have no device tree files. First things first. I'm using a
>> 4.1.x kernel so your output should be slightly different.
>> 
>> debian@beaglebone:~$ which dtc
>> /usr/local/bin/dtc
>> debian@beaglebone:~$ dtc --version
>> Version: DTC 1.4.1-ge733c7b8
>> 
>> You version should be something like 1.4.0-. If dtc is not installed
>> . . .
>> 
>> wget -c
>> https://raw.githubusercontent.com/RobertCNelson/tools/master/pkgs/dtc.sh
>> chmod +x dtc.sh
>> ./dtc.sh
>> 
>> debian@beaglebone:~$ dtc -v
>> Version: DTC 1.4.0-gf345d9e4
>> 
>> Then, Setup and compile dtbo's . . .
>> 
>> $ sudo apt-get install git
>> $ git clone https://github.com/beagleboard/bb.org-overlays
>> $ cd bb.org-overlays/
>> $ ./dtc-overlay.sh
>> 
>> Install dtbo's
>> $ sudo ./install.sh
>> 
>> 
>> Check /lib/firmware/:
>> $ ls /lib/firmware/
>> 
>> Let me know if you have any problems with that.
>> 
>> On Mon, Oct 19, 2015 at 9:57 AM, Ben Shapiro 
>> wrote:
>>> 
>>> So… I installed the image that Robert pointed me to. And things still
>>> aren’t working. Here’s some more info.
>>> 
>>> 
>>> root@beaglebone:/lib/firmware# ls /lib/firmware/
>>> dra7-ipu2-fw.xem4  dra7xx-m4-ipu2.xem4 vpdma-1b8.bin
>>> 
>>> None of them 

[beagleboard] Re: Reserving memory for writes to DDR from PRUs

[Andrew Szymkowiak]

Ok, as is usual, in hindsight, my error now seems massively idiotic.  If 
you call prussdrv_map_prumem, one gets a pointer to a region of memory, 
whose beginning corresponds to a zero offset from the corresponding 
constant table entry on the PRU.  So, after having gotten that to work, I 
decided by some magical thinking that prussdrv_map_extmem would work the 
same same.  But no, what it actually does is give you a pointer to a buffer 
which the uio_pruss driver has allocated.  It is then the user's 
responsibility to get the physical address of this buffer, and transmit it 
to the PRU, and use that as the starting address for i/o into this buffer.  
(I'd been trying to use offsets relative to the extmem entry in the 
constants table, which always starts at 0x8000 (+ offsets from writing 
into CTPPR_1), which was corrupting other things in the Linux memory...I 
guess I was hoping that the driver would somehow muscle the reserved buffer 
area to that address, though I now freely admit I'd have no idea how one 
could accomplish that, without having had the Linux VM system skip that 
range at boot with the MEMMAP entries...)

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

Re: [beagleboard] BeagleBone Green Grove i2c issues

[Ben Shapiro]

Hi Jason,

Which Python examples?

Ben

On Oct 20, 2015, at 8:49 PM, Jason Kridner 
> wrote:



On Oct 20, 2015, at 7:50 PM, Ben Shapiro 
> wrote:

Jason,

Thanks for trying to help. See below.

Ben

On Oct 20, 2015, at 2:01 PM, Jason Kridner 
> wrote:

On Mon, Oct 19, 2015 at 10:11 PM, Ben Shapiro 
> wrote:
Ok... so I've banged my head about this more and, have made some progress.
THANK YOU for your help thus far.

Still, this are really broken. As an example, the instructions here to blink
an LED don't work. They don't crash, but nothing happens on the board when I
run them. Suggestions?

It is difficult to check your work using the GUI (ie., clicking the
right button). Can you get to the command prompt (right there in
Cloud9 IDE) and do the following and capture the entire terminal
session and paste here?

# cat yourfile.py
# python yourfile.py


I’ve never used Cloud9 and have done everything from within SSH.

In any case, here’s the file:

debian@bonehog:~/making_bbg_work$ cat blink.py
import Adafruit_BBIO.GPIO as GPIO
import time
GPIO.setup("P9_14", GPIO.OUT)
while True:
GPIO.output("P9_14", GPIO.HIGH)
time.sleep(0.5)
GPIO.output("P9_14", GPIO.LOW)
time.sleep(0.5)

Running the script produces no output, either on the console or in the behavior 
of any of the LEDs.

P9_14 is a pin, not one of the built-in LEDs. I'll ping them to make that 
clearer.



On the bright side: Some grove devices now show up in i2cdetect. There are
others that don't. And I can't figure out how to get the non i2c port to
work as gpio (for example the LED example linked to above).

Are you doing 'i2cdetect -y 2’ ?

Yes. The Grove RGB LCD shows up. And I can even issue commands to activate and 
change the backlight color. But I can’t get any text to appear.

I had a similar challenge, but I think if I2C works, it must be something with 
the commands themselves. Have you checked out the Python examples? I will check 
it out myself tomorrow.



Depending on the kernel, you might be able to use 'config-pin’


I don’t know what config-pin is. And no file by that name exists on my device.


Have any of you actually gotten a BBG working with common grove sensors? For
example, the Digital Temp and Humidity sensor (I have the "pro" and the
non-pro versions)? Some example code would be really helpful.

I have. The code shipped with the board worked for me. I'm in process
of pushing it into the bone101 code.


Code shipped with the board??? Does it exist online somewhere?





On Monday, October 19, 2015 at 7:31:34 PM UTC-6, Ben Shapiro wrote:

I get this "reference is not a tree" error when following William's
instructions.
Commenting out the code that tries to use that sha seems to fix the
problem.


On Monday, October 19, 2015 at 1:10:27 PM UTC-6, William Hermans wrote:

@Robert

By the way Robert . . .

debian@beaglebone:~/bb.org-overlays$ ./dtc-overlay.sh
CLEAN (libfdt)
CLEAN (tests)
CLEAN
Already on 'master'
Already up-to-date.
fatal: reference is not a tree: f6dbc6ca9618391e4f30c415a0a09b7af35f7647

Kind of has me stuck . . . heh probably a bad idea for me to test
downgrade dtc . . .

On Mon, Oct 19, 2015 at 11:59 AM, William Hermans 
>
wrote:

Ok, so you have no device tree files. First things first. I'm using a
4.1.x kernel so your output should be slightly different.

debian@beaglebone:~$ which dtc
/usr/local/bin/dtc
debian@beaglebone:~$ dtc --version
Version: DTC 1.4.1-ge733c7b8

You version should be something like 1.4.0-. If dtc is not installed
. . .

wget -c
https://raw.githubusercontent.com/RobertCNelson/tools/master/pkgs/dtc.sh
chmod +x dtc.sh
./dtc.sh

debian@beaglebone:~$ dtc -v
Version: DTC 1.4.0-gf345d9e4

Then, Setup and compile dtbo's . . .

$ sudo apt-get install git
$ git clone https://github.com/beagleboard/bb.org-overlays
$ cd bb.org-overlays/
$ ./dtc-overlay.sh

Install dtbo's
$ sudo ./install.sh


Check /lib/firmware/:
$ ls /lib/firmware/

Let me know if you have any problems with that.

On Mon, Oct 19, 2015 at 9:57 AM, Ben Shapiro 
>
wrote:

So… I installed the image that Robert pointed me to. And things still
aren’t working. Here’s some more info.


root@beaglebone:/lib/firmware# ls /lib/firmware/
dra7-ipu2-fw.xem4  dra7xx-m4-ipu2.xem4 vpdma-1b8.bin

None of them mention i2c in the name (as William Hermans message
suggested one should).

However, this is as one would expect:
root@beaglebone:/lib/firmware# ls /boot/dtbs/`uname -r` |grep green
am335x-bonegreen-overlay.dtb
am335x-bonegreen.dtb

Output from i2cdetect is identical with before.

Other suggestions?

Ben


On Oct 18, 2015, at 2:51 PM, William Hermans 

Re: [beagleboard] BeagleBone Green Grove i2c issues

[William Hermans]

Ben, in addition to what Jason will tell you . . .

https://github.com/graycatlabs/PyBBIO
Check out the documentation links.

Here is his USR LED blink example.
https://github.com/graycatlabs/PyBBIO/blob/master/examples/blink.py


Trust me though. I know exactly how frustrating it is to get something
working on the Beaglebone( sometimes ). As there is a lot of FUD out there,
and when you're inexperienced with various aspects of the hardware. It can
make things difficult.

Alexanders code should be good though, and do not be put off that it was
originally written for the Beaglebone white. As what works on the White
generally works on the Black, and by extension should work on the green
too. I've been writing code lately using a git project that was original
intended for the White. . . But peripheral register addresses, etc I am
finding are exactly the same. The grove stuff though . . . I know nothing
about.

The majority of issues you'll run into is: If documentation, or a project
is too old, they'll talk about using Angstrom. Like with Alexanders
documentation from the link above covers Angstrom, and Ubuntu / Debian.
Disregard the Angstrom bits. His stuff seems to usually be very thorough -
though.


On Tue, Oct 20, 2015 at 7:56 PM, Ben Shapiro 
wrote:

> Hi Jason,
>
> Which Python examples?
>
> Ben
>
> On Oct 20, 2015, at 8:49 PM, Jason Kridner  wrote:
>
>
>
> On Oct 20, 2015, at 7:50 PM, Ben Shapiro  > wrote:
>
> Jason,
>
> Thanks for trying to help. See below.
>
> Ben
>
> On Oct 20, 2015, at 2:01 PM, Jason Kridner 
> wrote:
>
> On Mon, Oct 19, 2015 at 10:11 PM, Ben Shapiro 
> wrote:
>
> Ok... so I've banged my head about this more and, have made some progress.
> THANK YOU for your help thus far.
>
> Still, this are really broken. As an example, the instructions here to
> blink
> an LED don't work. They don't crash, but nothing happens on the board when
> I
> run them. Suggestions?
>
>
> It is difficult to check your work using the GUI (ie., clicking the
> right button). Can you get to the command prompt (right there in
> Cloud9 IDE) and do the following and capture the entire terminal
> session and paste here?
>
> # cat yourfile.py
> # python yourfile.py
>
>
> I’ve never used Cloud9 and have done everything from within SSH.
>
> In any case, here’s the file:
>
> debian@bonehog:~/making_bbg_work$ cat blink.py
> import Adafruit_BBIO.GPIO as GPIO
> import time
> GPIO.setup("P9_14", GPIO.OUT)
> while True:
> GPIO.output("P9_14", GPIO.HIGH)
> time.sleep(0.5)
> GPIO.output("P9_14", GPIO.LOW)
> time.sleep(0.5)
>
> Running the script produces no output, either on the console or in the
> behavior of any of the LEDs.
>
>
> P9_14 is a pin, not one of the built-in LEDs. I'll ping them to make that
> clearer.
>
>
>
> On the bright side: Some grove devices now show up in i2cdetect. There are
> others that don't. And I can't figure out how to get the non i2c port to
> work as gpio (for example the LED example linked to above).
>
>
> Are you doing 'i2cdetect -y 2’ ?
>
>
> Yes. The Grove RGB LCD shows up. And I can even issue commands to activate
> and change the backlight color. But I can’t get any text to appear.
>
>
> I had a similar challenge, but I think if I2C works, it must be something
> with the commands themselves. Have you checked out the Python examples? I
> will check it out myself tomorrow.
>
>
>
> Depending on the kernel, you might be able to use 'config-pin’
>
>
> I don’t know what config-pin is. And no file by that name exists on my
> device.
>
>
> Have any of you actually gotten a BBG working with common grove sensors?
> For
> example, the Digital Temp and Humidity sensor (I have the "pro" and the
> non-pro versions)? Some example code would be really helpful.
>
>
> I have. The code shipped with the board worked for me. I'm in process
> of pushing it into the bone101 code.
>
>
> Code shipped with the board??? Does it exist online somewhere?
>
>
>
>
>
> On Monday, October 19, 2015 at 7:31:34 PM UTC-6, Ben Shapiro wrote:
>
>
> I get this "reference is not a tree" error when following William's
> instructions.
> Commenting out the code that tries to use that sha seems to fix the
> problem.
>
>
> On Monday, October 19, 2015 at 1:10:27 PM UTC-6, William Hermans wrote:
>
>
> @Robert
>
> By the way Robert . . .
>
> debian@beaglebone:~/bb.org-overlays$ ./dtc-overlay.sh
> CLEAN (libfdt)
> CLEAN (tests)
> CLEAN
> Already on 'master'
> Already up-to-date.
> fatal: reference is not a tree: f6dbc6ca9618391e4f30c415a0a09b7af35f7647
>
> Kind of has me stuck . . . heh probably a bad idea for me to test
> downgrade dtc . . .
>
> On Mon, Oct 19, 2015 at 11:59 AM, William Hermans 
> wrote:
>
>
> Ok, so you have no device tree files. First things first. I'm using a
> 4.1.x kernel so your output should be slightly 

Re: [beagleboard] Re: Reserving memory for writes to DDR from PRUs

[William Hermans]

>
> *Ok, as is usual, in hindsight, my error now seems massively idiotic*
>

Sounds like you learned something though ! Don't worry however, because
you're not alone.



On Tue, Oct 20, 2015 at 7:16 PM, Andrew Szymkowiak  wrote:

> Ok, as is usual, in hindsight, my error now seems massively idiotic.  If
> you call prussdrv_map_prumem, one gets a pointer to a region of memory,
> whose beginning corresponds to a zero offset from the corresponding
> constant table entry on the PRU.  So, after having gotten that to work, I
> decided by some magical thinking that prussdrv_map_extmem would work the
> same same.  But no, what it actually does is give you a pointer to a buffer
> which the uio_pruss driver has allocated.  It is then the user's
> responsibility to get the physical address of this buffer, and transmit it
> to the PRU, and use that as the starting address for i/o into this buffer.
> (I'd been trying to use offsets relative to the extmem entry in the
> constants table, which always starts at 0x8000 (+ offsets from writing
> into CTPPR_1), which was corrupting other things in the Linux memory...I
> guess I was hoping that the driver would somehow muscle the reserved buffer
> area to that address, though I now freely admit I'd have no idea how one
> could accomplish that, without having had the Linux VM system skip that
> range at boot with the MEMMAP entries...)
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] HDMI License

[Charles Steinkuehler]

HDMI <> HDCP

You don't _have_ to have encryption to be HDMI certified, so the
existing framer is OK.  But you still need to be certified and pay a
royalty if you want to use the HDMI logo.  At my day job we ship
several products with non-encrypted HDMI, all of which are certified
and use the official HDMI logo (and yes, we pay royalties to the HDMI
folks).

If you want to support encryption, in addition to being HDMI
certified, you also have to license and go through the certification
process for HDCP.  That is *MUCH* harder than the process for HDMI
certification, and would likely be virtually impossible for an
open-source platform like the BeagleBone.  Even if you switched out to
the HDMI chip that supports encryption, the raw video signals are
available on the expansion header, which is a *BIG* problem for HDCP
certification!

On 10/19/2015 8:41 AM, Gerald Coley wrote:
> Encryption is not supported. We use an HDMI framer but we are not HDMI
> certified. So unless you want the HDMI logo, there is no need for a license.
> 
> If you want the Logo then you need to get it certified and you must replace
> the framer with the more expensive version of the framer that supports the
> encryption.
> 
> Gerald
> 
> 
> On Mon, Oct 19, 2015 at 1:50 AM,  wrote:
> 
>> hi
>>
>> If we sold incorporating the BBB in our product,
>> do we have to pay the HDMI of royalty?
>>
>> We do not use the HDMI logo.
>>
>> We asked TI about this question, but they were introduced here.
>> Please tell me if you know.
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

-- 
Charles Steinkuehler
char...@steinkuehler.net

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

[beagleboard] Re: Instructions to get OpenGL ES acceleration on BeagleBone Black running Debian

[murali . dave]

Hi Juozapas ,

I'm really excited to see that you can get the OpenGL ES working on the 
beagleboneblack.
I have a beagleboneblack connected to a LCD touch panel and I have the SGX 
modules installed(followed instructins from Robert nelson's page).
I'm trying to run QT  dashboard example project. But the program errors out 
with the message that the 
program : Could not initialize egl display. I could not find answers 
related to this issue. 

Did you happen to come across similar issue? I would appreciate if you can 
share some information.

Thanks,
Murali

On Wednesday, 14 October 2015 20:45:41 UTC+2, Juozapas Adomaitis wrote:
>
> Hello,
>
> I have been researching the possibility to run Qt Quick 2
> applications directly on BeagleBoard Black rev. C with the
> display connected to HDMI. In the process I have put together
> instructions to get OpenGL ES acceleration working (which is a
> required by Qt Quick 2). I am posting them here in the hope that
> they can be useful to someone.
>
> Regarding my experiments, the HDMI port worked with 2 monitors
> out of 4 I have tried - disappointing. Qt Quick 2 was impossibly
> slow using software rendering under X in 24bpp mode. I couldn't
> get it to run in 16bpp mode; it displayed this error:
>Cant find EGLConfig, returning null config
>Unable to find an X11 visual which matches EGL config 0
>Could not initialize OpenGL
> It worked ok in fullscreen mode (EGLFS) after installing the
> drivers.
>
> ==
> 3 steps to get hardware OpenGL ES acceleration on BeagleBone
> Black running Debian (tested 2015-10 on wheezy, jessie and sid).
>
> Note that after following the steps you will be able to run a
> single fullscreen OpenGL ES application (e.g. Qt Quick 2 in EGLFS
> mode) and nothing else, meaning:
> * 3D acceleration in X server doesn't work on BBB and apparently
>   won't work anytime in the future
> * Wayland can run with accelerating compositing (window drawing
>   handled by the GPU chip), but starting OpenGL applications
>   won't work. For this to work the graphics driver must have
>   built-in Wayland support, exposing the EGL_EXT_platform_wayland
>   EGL extension. Robert Nelson mentioned on IRC that TI is
>   working on this and progress can be followed here:
>   
> http://git.ti.com/gitweb/?p=graphics/omap5-sgx-ddk-um-linux.git;a=summary
>
> 1. First pick a kernel version from this list of kernel modules
>for the GPU (the packages are from the
>http://repos.rcn-ee.com/debian/ repo):
>$ apt-cache search ti-sgx-es8-modules
>Then install the kernel together with the modules. For
>example, if you picked ti-sgx-es8-modules-3.14.54-ti-r77, run:
>$ apt-get install -y 
> {ti-sgx-es8-modules,linux-image,linux-firmware-image}-3.14.54-ti-r77
> 2. On an x86 Linux computer run this (an x86 host is needed
>because an x86 binary installer from TI will be unpacked):
>$ git clone https://github.com/RobertCNelson/ti-linux-kernel-dev.git
>$ cd ti-linux-kernel-dev
>$ ./sgx_create_package.sh
>$ scp deploy/GFX_*_es8.x.tar.gz :/tmp/
> 3. Now install the utilities on your BBB and reboot:
>$ cd /
>$ sudo tar zxf /tmp/GFX_*_es8.x.tar.gz
>$ sudo /opt/gfxinstall/sgx-install.sh
>
> Qt Quick 2 fullscreen programs can be launched from the terminal
> or within Wayland by exporting these variables:
> $ export QT_QPA_PLATFORM=eglfs
> $ export QT_QPA_EVDEV_KEYBOARD_PARAMETERS="grab=1"
> $ export QT_QPA_EVDEV_MOUSE_PARAMETERS="grab=1"
>
> Wayland with accelerated compositing (but without the possibility
> to launch windowed OpenGL programs) can be run like this:
> $ weston-launch -- --backend=fbdev-backend.so --use-gl
>
>

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