Re: [beagleboard] BeagleBone Green Grove i2c issues

[Mike]

On 10/18/2015 05:59 PM, William Hermans wrote:
My best guess is that I2C1 is brought out to the I2C connector, so 
enabling BB-I2C1-00A0.dtbo should work for you.


On Sun, Oct 18, 2015 at 2:43 PM, Ben Shapiro > wrote:


Sadly, there does not seem to be a BBG-specific image.






On Fri, Oct 16, 2015 at 10:12 AM, Ben Shapiro
 wrote:

(apologies if this is a double-post... my first
submission does not seem to have gone through)

Hi,

I've been having a hell of a time getting the
BeagleBone Green to see Grove devices connected to
it.

Running i2cdetect -r 0 results in the following
output regardless of which Grove sensors are
connected:

# i2cdetect  -r 0
WARNING! This program can confuse your I2C bus,
cause data loss and worse!
I will probe file /dev/i2c-0 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
 0  1  2  3 4  5  6  7  8 9  a  b  c  d e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Similarly, i2cdetect -r 1 always results in the
following output:

# i2cdetect  -r 1
WARNING! This program can confuse your I2C bus,
cause data loss and worse!
I will probe file /dev/i2c-1 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
 0  1  2  3 4  5  6  7  8 9  a  b  c  d e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --


Why do you think that they aren't enabled?  The output of i2cdetect -r 1 
shows the 4 cape eeprom addresses in use.  The output of i2cdetect shows 
two addresses.  How about the output of "dmesg | grep cape" "dmesg | 
grep i2c" ?


Mike

--
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] Status of pruss in 4.1.10-ti-r21/2015-10-11 Debian snapshot?

[Robert Nelson]

On Sun, Oct 18, 2015 at 7:05 PM, Rick Mann  wrote:
> Pruss is still broken in the 4.1.10-ti-r21 kernel, right?
>
> Does anyone know if the new remoteproc thing can be used to download existing 
> firmware that was built with pruss in mind, and how I could modify my code to 
> use that instead?
>

another user got it working with remoteproc, he's just waiting for a
beta-x15 to arrive so that they will work the same on both boards..

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] Kernel 4.1.9 overlays not working

[Robert Nelson]

On Sun, Oct 18, 2015 at 8:42 PM, codemonkey  wrote:
> Robert, I have the same question about the source of DTC 1.4.1-gXYZXYZXYZ -
> I installed the device-tree-overlay package into a new build (Linux
> beaglebone 4.1.10-bone-rt-r16 #1 Sun Oct 4 09:05:14 UTC 2015 armv7l
> GNU/Linux) and checked the version of dtc. It was v1.4.0. I tried running
> ./dtc_overlay.sh, but the version didn't change. So, I cloned the git
> repository of the source at devicetree.org, did a make and make install. The
> version is still 1.4.0. The only reference Google has to the string in your
> readme (DTC 1.4.1-gXYZXYZXYZ) points to your readme.

It's installed too:

/usr/local/bin/

https://github.com/beagleboard/bb.org-overlays/blob/master/dtc-overlay.sh#L56

If it doesn't work, your PATH is mangled..

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

[Robert Nelson]

Make sure you have it connected to the correct Grove connector, one is
i2c2 (same bus as the "cape eeprom") the other is usart2...

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.

[beagleboard] Installing/booting latest Angstrom build (2015-10) on BBB

[ahebert]

TL;DR --> How do I boot my BBB (rev C) from a recent 2015 build of Angstrom 
(ideally one I don't have to compile myself)?

The latest Angstrom images for the BBB 
 are dated 2013-06, and I want to get 
the latest version working on my BBB. I notice that the Debian images are 
much more recent, but I prefer the fast boot-time of the Angstrom distro.

I tried the following:

   1. From 
http://dominion.thruhere.net/angstrom/nightlies/v2015.12/beaglebone/, 
   downloaded:
  1. MLO
  2. u-boot.img
  3. systemd-image-beaglebone.tar.gz
  4. modules-beaglebone.tgz
   2. On my SD card:
  1. Create bootable FAT16 partition and copy MLO and u-boot.img to it.
  2. Create an EXT4 partition and copy systemd-image-beaglebone.tar.gz 
  and modules-beaglebone.tgz to it.
   3. Per this discussion 
    
   on yoctoproject, I did NOT add any uEnv.txt or zImage file to the boot 
   partition, and I am expecting it to boot from the kernel images under the 
   /boot/ directory from systemd-image-beaglebone.tar.gz.
   4. After inserting my SD card and powering up my BBB, I see some 
   blinking lights, but no output from the serial port (tty01), and no 
   response to my attempts to SSH in.


I have a 2014 build of Angstrom from 3rd-party vendor Chipsee, which works 
on my BBB. With that image is included the following uEnv.txt:

bootargs=console=ttyO1,115200n8 root=/dev/mmcblk0p2 rootfstype=ext4 
> rootwait quiet ;
>
> bootcmd=mmc rescan ; mmc dev 0 ; fatload mmc 0 0x80007fc0 uImage ; fatload 
> mmc 0 0x80F8 am335x-bbb-exp.dtb ; bootm 0x80007fc0 - 0x80F8;
>
> uenvcmd=boot;
>

I don't know much about u-boot, or how to debug the boot process. I will be 
grateful for pointers there if that's what needs doing. I know some of the 
commands above won't work because the latest Angstrom builds use zImage 
files instead of uImage files. Also, I don't know how to choose the correct 
addresses for the `fatload mmc` command, if that's required here.

Thanks in advance for any help!

-- 
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] Re: Beaglebone Black : miss mii.ko and usbnet.ko so no USB to ethernet converter work !

[Matteo Loda]

Bingo Robert !

Sorry for time I took but I was very busy  the problem was exactly the
udev/rules  the system recognized the asix mac address  but assigned
him the eth2 interface  the eth1 was assigned to another asix mac
address, not the mine. I changed the assignement and now everything works.

So Robert  I can only say " thank you  " :)

Now I am fighting with xenomai kernel ... compile ok , install ok but I
have boot trouble...

Maybe I will open another topic about this

Thanks again

Matt



2015-09-15 16:23 GMT+02:00 Robert Nelson :

> That's just udev persistent network names. Look under /etc/udev/rules...
> On Sep 15, 2015 8:39 AM, "Matteo Loda"  wrote:
>
>> Hi Robert, This is what happened:
>>
>> 1) Debian in the SD card:
>>
>> TERMINAL:
>>
>> debian@beaglebone:/etc$ cat dogtag
>> BeagleBoard.org Debian Image 2015-03-01
>>
>>
>> debian@beaglebone:~$ ifconfig -a
>> eth0  Link encap:Ethernet  HWaddr d0:39:72:54:05:e4
>>   inet addr:10.22.189.89  Bcast:10.22.255.255  Mask:255.255.0.0
>>   inet6 addr: fe80::d239:72ff:fe54:5e4/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:2502 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:195 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:264416 (258.2 KiB)  TX bytes:22276 (21.7 KiB)
>>   Interrupt:40
>>
>> eth2  Link encap:Ethernet  HWaddr 00:50:b6:63:39:02
>>   BROADCAST MULTICAST  MTU:1500  Metric:1
>>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>>
>> loLink encap:Local Loopback
>>   inet addr:127.0.0.1  Mask:255.0.0.0
>>   inet6 addr: ::1/128 Scope:Host
>>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:0
>>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>>
>> usb0  Link encap:Ethernet  HWaddr 76:21:05:26:66:13
>>   inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
>>   inet6 addr: fe80::7421:5ff:fe26:6613/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:144 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:116 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:20261 (19.7 KiB)  TX bytes:25466 (24.8 KiB)
>>
>> I defined eth1 in interfaces , not eth2 . The MAC 00:50:b6:63:39:02 is
>> that of the USB to Ethernet Adapter.
>>
>>
>> 2) Debian eMCC
>>
>> TERMINAL
>>
>> debian@beaglebone:~$ uname -r
>> 4.1.6-ti-r14
>> debian@beaglebone:~$ uname -a
>> Linux beaglebone 4.1.6-ti-r14 #1 SMP PREEMPT Thu Sep 3 20:56:12 UTC 2015
>> armv7l GNU/Linux
>>
>> debian@beaglebone:~$ sudo ifconfig
>> eth0  Link encap:Ethernet  HWaddr d0:39:72:54:05:e4
>>   inet addr:10.22.189.89  Bcast:10.22.255.255  Mask:255.255.0.0
>>   inet6 addr: fe80::d239:72ff:fe54:5e4/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:3268 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:219 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:289954 (283.1 KiB)  TX bytes:30615 (29.8 KiB)
>>   Interrupt:170
>>
>> eth1  Link encap:Ethernet  HWaddr 00:50:b6:63:39:02
>>   inet addr:10.22.189.41  Bcast:10.22.255.255  Mask:255.255.0.0
>>   inet6 addr: fe80::250:b6ff:fe63:3902/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:3327 errors:0 dropped:5 overruns:0 frame:0
>>   TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:241860 (236.1 KiB)  TX bytes:6258 (6.1 KiB)
>>
>> loLink encap:Local Loopback
>>   inet addr:127.0.0.1  Mask:255.0.0.0
>>   inet6 addr: ::1/128 Scope:Host
>>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:0
>>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>>
>> usb0  Link encap:Ethernet  HWaddr d0:39:72:54:05:e0
>>   inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
>>   inet6 addr: fe80::d239:72ff:fe54:5e0/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:94 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 

[beagleboard] problem: 2015 beaglebone images & xenomai boot

[lodamatteo]

Hi guys

I am following these guide to install xenomai on my beaglebone SD card 
system:installing xenomai on beaglebone 


this guide uses an old image:  
http://debian.beagleboard.org/images/bone-debian-7.5-2014-05-14-2gb.img.xz

I want to use a new image , for example 
https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.x
 


There is a problem: the guide installing xenomai on beaglebone 

 uses 
an image in which we have:

1) boot partition with zImage ( for example on my pc /dev/sdb1)
2) rootfs partition  ( for example on my pc /dev/sdb2 )

The 2015 images I have found have only :

1) rootfs partition , with boot folder  / for example on my pc /dev/sdb1 
with boot flag )

So I am not able, following xenomai guides, to let the xenomai kernel boot. 
(.I am able to install it but not able to boot it ...) Because in this 
guide (and others) they say to change the original zImage files (or uImage) 
with the equivalent xenomai zImage. 

I tryed to copy the zImage / uImage in the boot folder but it doesn't work 
.. in the uEnv.txt files I found no solutions.

I have try to build a beaglebone image following the 
github.com/beagleboard/image-builder , but I obtain only image with a 
single partition.

So ... I have three questions

1) How could I build a 2015 image with two partition , so I can follow the 
xenomai install guide ? 

or

2) How could I configure the boot to choose xenomai ( so without following 
the xenomai guide I have found ) ? 

3) In the 2015 images  /rootfs/boot/uboot  is empty ... Have I to copy in 
this folder the xenomai uImage ? 

Thanks a lot

Matt

-- 
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 refusing to boot

[rohan . preacher . smith]

Hi,
I managed to get it to print out a new error, "bad magic", which should be 
0x27051956 and is the first 4 bytes of u-boot.img. Modified u-boot to print 
out what it's actually getting and it varies the first few times it powers 
up, but then becomes consistently 0xF6EFFADE, which implies it's failing to 
completely initialise something. This happens regardless of the SD card 
used.

Cheers,
Rohan Smith

On Friday, 16 October 2015 01:20:48 UTC+10, rohan.prea...@gmail.com wrote:
>
> I get no difference in output whether I put MLO at 128k and u-boot.img at 
> 384k using those instructions, or if I put it on a boot partition.
>
> Cheers,
> Rohan Smith
>
> On Thursday, 15 October 2015 23:36:45 UTC+10, RobertCNelson wrote:
>>
>> On Thu, Oct 15, 2015 at 6:24 AM, Rohan Smith 
>>  wrote: 
>> > Hi, 
>> > I recently tried to update the OS on a stock Beaglebone Black. The BBB 
>> now 
>> > refuses to boot off of either the eMMC or an SD card. 
>> > 
>> > Booting from the eMMC lights up the power LED, no user LEDs, and 
>> outputs the 
>> > character 'C' a bunch of times on the serial line. 
>> > 
>> > Booting from the SD card, partitioned with partition 0 as fat16 via 
>> > mkfs.vfat -F 16 and partition 1 as ext4 with mkfs.ext4 results in this 
>> > output: http://pastebin.com/14E8AwAD 
>> > Booting from the SD card, with MLO at 128k and u-boot.img at 384k 
>> results in 
>> > the same thing. 
>> > 
>> > How am I able to restore the BBB to a usable system? 
>>
>>
>> https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSDcard
>>  
>>
>> 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.

[beagleboard] long headers for BBB?

[bmstekllc]

I want to attach a BBB to another larger board without cutting a hole in 
the board for the ethernet module as the capes do.
Anyone know of a long header setup that will achieve this?

A standard header with 0.1" high black plastic piece and really long pins 
is not good enough since there is nothing to prevent the user pushing the 
board down until the ethernet module hits the board.

What I am looking for is a male header with perhaps 1/4" high plastic piece 
or some combination of Male.femaie parts to get the spacing.

The LCD capes seem to use such a part but search on the part number in the 
BOM comes up empty.

Any ideas how to do this?

Bill

-- 
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: libpruio (fast and easy D/A - I/O)

[akj1989]

Hi TJF,

I am trying to use the example you provided here to sample an analog signal.
With the default setting of tmr=5000, I am getting configuration error:

config failed: sample rate too big

It works with tmr=2 and dumps the data into 2 files. Though the data 
looks to be in binary format.

Could there be something in my setup that may need tweaking to run this at 
200KHz?
I am using libpruio v0.2 and installed it following the steps mentioned here 

.

Thanks,
Akshay

On Monday, November 10, 2014 at 8:10:04 AM UTC-5, TJF wrote:
>
> Oups, found a buck right when I posted:
>
> line 70
> SWAP p0, p1 : EXIT DO
>
> should be
> SWAP p0, p1 : EXIT WHILE
>
> Soory!
>

-- 
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] Talking to BBB with OS X 10.11 (El Capitan)

[jazzkayak]

Has anyone been able to connect to the BBB running OS X El Cap? The driver 
provided on the getting started page is long since obsolete (FTDI driver) 
and http://www.joshuawise.com doesn't seem to exist anymore (404). If I 
look at the IP address assigned to it and try to SSH in, it just times out.

Cheers, Joe

-- 
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] BeagleBone GREEN: Can't get grove devices to show up... anyone else?

[rysh0961]

Hi,

I've been having a hell of a time getting the BeagleBone Green to see Grove 
devices connected to it.

Running i2cdetect -r 0 results in the following output regardless of which 
Grove sensors are connected:

# i2cdetect  -r 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Similarly, i2cdetect -r 1 always results in the following output:

# i2cdetect  -r 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

I tried reflashing my board with the 2015-07-28 eMMC Flasher (console) 
image. My current uname -a output is: Linux greenbone 3.8.13-bone72 #1 SMP 
Tue Jun 16 21:36:04 UTC 2015 armv7l GNU/Linux. 
However, flashing  did not help. 

I also tried on a second board. Same problem. 
The BBG Alarm System code 
 posted on the BBG 
product page also will not run.

Am I doing something wrong?

Thank you,
Ben



-- 
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] SPI's Beginner Guide

[alvjorge]

Hi,

testing different kind of sensors/modules provide the change to work with 
the several buses the BeagleBone Black has.

Now, I'm playing with an analog light sensor connected to an ADC which 
communicate with BBB through SPI bus. 
So, the first step I need to do is enable the SPI. Then, test SPI with 
loopback example. And finally, build the code to read from the ADC the 
light sensor data.

BeagleBone Black has:

   - OS: Debian
   - Kernel: 3.8.13-bone78
   - Kernel version: #1 SMP Sat Sep 26 09:11:50 UTC 2015

To enable SPI0, I have followed this guide, SPIDEV 
. During the guide steps 
implementation I have found some doubts/issues, so I will explain the 
procedure I has followed with its results in order to get the more precise 
help as possible.

   1. Create and Edit: *BB-SPI0-01-00A0.dts*
   2. Compile: *BB-SPI0-01-00A0.dts*
   3. Copy, *BB-SPI0-01-00A0.dtbo*, to: */lib/firmware/*
   4. Enable the Device Overlay Tree: 
  - *echo BB-SPI0-01 > /sys/devices/bone_capemgr.*/slots*
  - At my system '*' is '9'.
  5. Edit: */boot/uboot/uEnv.txt* file to add next line:
  - *optargs=quiet drm.debug=7 capemgr.enable_partno=BB-SPI0-01*
  6. Reboot.
   7. List SPI buses enabled: *ls -al /dev/spidev0.**
  - *ISSUE1*: there is no SPI bus enabled. I need to repeat the step 4 
  to finally enabled the SPI bus. So, I have added that line to '.profile' 
to 
  have SPI enabled with every bootup. Is there any mistake at this 
behaviour?
   8. Show pingroups:
  - *cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups*
  1. group: spi0_pins_s0
 2. pin 84 (44e10950)
 3. pin 85 (44e10954)
 4. pin 86 (44e10958)
 5. pin 87 (44e1095c)
 - *QUESTION1*: How can I find out which address correspond to a 
  pin? I tried to find it at BBB_SRM but there is no info about.
   

Now, it is time to check SPI running a loopback example. The SPIDEV 
 guide tells to shorcut 
pins 29 & 30 for SPI1, so for SPI0 pins are 18 & 21.
But, here start new problems:

   1. Next step ask for apply *diff to the kernel*.
  - *diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c*
  - Output: diff: unrecognized option '--git'
 - *ISSUE2*: Moreover, there is no spidev.c at BBB system. No diff 
 can be made.
  2. Finally, test the SPI with '*spidev_test*' program.
  - *QUESTION2*: Where is that file? Or the path, 
  *kernel/Documentation/spi*?
   

Well, once we reach this point there is only one thing more I would like to 
know. If I write a new code to work with SPI & sensors, *which libraries 
should be added*? (Maybe, <*linux/spi/spidev.h*> will be enough).

Kind Regards.

-- 
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] Status of pruss in 4.1.10-ti-r21/2015-10-11 Debian snapshot?

[Robert Nelson]

On Sun, Oct 18, 2015 at 8:52 PM, Rick Mann  wrote:
>
>> On Oct 18, 2015, at 17:11 , Robert Nelson  wrote:
>>
>> On Sun, Oct 18, 2015 at 7:05 PM, Rick Mann  wrote:
>>> Pruss is still broken in the 4.1.10-ti-r21 kernel, right?
>>>
>>> Does anyone know if the new remoteproc thing can be used to download 
>>> existing firmware that was built with pruss in mind, and how I could modify 
>>> my code to use that instead?
>>>
>>
>> another user got it working with remoteproc, he's just waiting for a
>> beta-x15 to arrive so that they will work the same on both boards..
>
> Oh, do you remember who that was?

Yeap, he will post it when he's ready.

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] Talking to BBB with OS X 10.11 (El Capitan)

[Robert Nelson]

On Fri, Oct 16, 2015 at 5:18 PM,   wrote:
> Has anyone been able to connect to the BBB running OS X El Cap? The driver
> provided on the getting started page is long since obsolete (FTDI driver)
> and http://www.joshuawise.com doesn't seem to exist anymore (404). If I look
> at the IP address assigned to it and try to SSH in, it just times out.

Yes, I know it's hard to believe the original "2014-05-14" image, is
that far out of date! What were we thinking not to "support" 10.11 2
springs ago!!!

Please read the first paragraph of the author's website on horndis for
10.11 updates:

http://www.joshuawise.com/horndis

The 2015-07-28 and lxqt snapshots here:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

contain: HoRNDIS-rel7.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] Kernel 4.1.9 overlays not working

[William Hermans]

http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/

On Sun, Oct 18, 2015 at 7:07 PM, Robert Nelson 
wrote:

> On Sun, Oct 18, 2015 at 8:42 PM, codemonkey  wrote:
> > Robert, I have the same question about the source of DTC
> 1.4.1-gXYZXYZXYZ -
> > I installed the device-tree-overlay package into a new build (Linux
> > beaglebone 4.1.10-bone-rt-r16 #1 Sun Oct 4 09:05:14 UTC 2015 armv7l
> > GNU/Linux) and checked the version of dtc. It was v1.4.0. I tried running
> > ./dtc_overlay.sh, but the version didn't change. So, I cloned the git
> > repository of the source at devicetree.org, did a make and make
> install. The
> > version is still 1.4.0. The only reference Google has to the string in
> your
> > readme (DTC 1.4.1-gXYZXYZXYZ) points to your readme.
>
> It's installed too:
>
> /usr/local/bin/
>
>
> https://github.com/beagleboard/bb.org-overlays/blob/master/dtc-overlay.sh#L56
>
> If it doesn't work, your PATH is mangled..
>
> 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.
>

-- 
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] xenomai boot on beaglebone debian 2015 image SD card: how ?

[William Hermans]

Matteo,

Robert's method will get you the whole thing installed, including xenomai
"specific" rootfs. Which I'm not all that familiar with, but I've been told
this contains xenomai utilities, examples, test suites, and what not.

On Sun, Oct 18, 2015 at 12:25 PM, Matteo Loda  wrote:

> Thank you very much William !
>
> Robert you are more real time than a real time kernel ^^
>
> I will try both the way and I will tell you the results
>
> Have a nice Sunday Evening :)
>
> Matt
>
>
>
>
>
> 2015-10-18 19:13 GMT+02:00 Robert Nelson :
>
>>
>> On Oct 18, 2015 10:08 AM, "Matteo Loda"  wrote:
>> >
>> > Hi guys
>> >
>> > I try to send again this topic , so if this is a duplicate I apologize
>> >
>> > I am following this
>> guide: installing-xenomai-on-beaglebone-using-debian-distribution
>> >
>> > They use a bone-debian-7.5-2014-05-14-2gb.img.xz.
>> >
>> > So they have two partition on the SD card Image
>> >
>> > 1) boot partition with zImage files ,they change  original debian
>> zImage with xenomai zImage
>> > 2) rootfs partition
>> >
>> > I try to use a 2015 debian image: bone-debian-7.8-2015-03-01-2gb.img.xz
>> >
>> > But I have only a single partition , with a boot folder, in which I
>> have no zImage
>> >
>> > So how could I boot xenomai ?
>> >
>> > I followed another way: build an image.
>> >
>> > I tryed the github.com/beagleboard/image-builder form RobertCNelson ,
>> but I obtain, with a 2015 image, a single SD partition.
>> >
>> > Could you tell me how to configure image-builder to build a separated
>> boot partition with the image-builder ? ( 2015 debian image 3.8 kernel)
>>
>> Pre built image is available here:
>>
>>
>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29_Machinekit
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/5HDjgE4r-9U/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>

-- 
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

[William Hermans]

> *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 two I2C device tree overlays which I
can load. One generic I2C, and another which is unfamiliar to me, but seems
to be for a specific device.

>From here you should be able to load the first dtbo file if you have the
same on your board, and be able to use your I2C utilities. Do however keep
in mind that I am completely unfamiliar with the BBG. So I do not know
anything about the grove connectors, how they work, how they're connected
to board, and all that. So before going off half cocked based on what I'm
saying, you should double check what you can.

But if you have further questions, I'd be glad to help. I do have interest
in the BBG . . . But we already own 5 blacks . . .

On Sun, Oct 18, 2015 at 12:25 PM, Ben Shapiro 
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
>
>
> On Sunday, October 18, 2015 at 12:10:59 PM UTC-6, William Hermans wrote:
>>
>> Hi Ben,
>>
>> Have you resolved your issue yet ? Personally I have not used I2C on any
>> Beaglebone yet. However I thought I might mention that for most ( perhaps
>> all ) devices of this nature on the Beaglebone's you need to load a device
>> tree file, which in turn often loads needed kernel module drivers, sets the
>> pins up, etc.
>>
>> On Fri, Oct 16, 2015 at 10:12 AM, Ben Shapiro 
>> wrote:
>>
>>> (apologies if this is a double-post... my first submission does not seem
>>> to have gone through)
>>>
>>> Hi,
>>>
>>> I've been having a hell of a time getting the BeagleBone Green to see
>>> Grove devices connected to it.
>>>
>>> Running i2cdetect -r 0 results in the following output regardless of
>>> which Grove sensors are connected:
>>>
>>> # i2cdetect  -r 0
>>> WARNING! This program can confuse your I2C bus, cause data loss and
>>> worse!
>>> I will probe file /dev/i2c-0 using read byte commands.
>>> I will probe address range 0x03-0x77.
>>> Continue? [Y/n] y
>>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
>>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 70: -- -- -- -- -- -- -- --
>>>
>>> Similarly, i2cdetect -r 1 always results in the following output:
>>>
>>> # i2cdetect  -r 1
>>> WARNING! This program can confuse your I2C bus, cause data loss and
>>> worse!
>>> I will probe file /dev/i2c-1 using read byte commands.
>>> I will probe address range 0x03-0x77.
>>> Continue? [Y/n] y
>>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 70: -- -- -- -- -- -- -- --
>>>
>>> I tried reflashing my board with the 2015-07-28 eMMC Flasher (console)
>>> image. My current uname -a output is: Linux greenbone 3.8.13-bone72 #1
>>> SMP Tue Jun 16 21:36:04 UTC 2015 armv7l GNU/Linux.
>>> However, flashing did not help.
>>>
>>> I also tried on a second board. Same problem.
>>> The BBG Alarm System code
>>>  posted on the BBG
>>> product page also will not run.
>>>
>>> Am I doing something wrong?
>>>
>>> Thank you,
>>> Ben
>>>
>>>
>>>
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To 

Re: [beagleboard] BeagleBone Green Grove i2c issues

[William Hermans]

>
> *$ ls /lib/firmware/ | grep I2C*
> *BB-I2C1-00A0.dtbo*
> *BB-I2C1-PCA9685-00A0.dtbo*
>
> *Looks like, at least for me, I have two I2C device tree overlays which I
> can load. One generic I2C, and another which is unfamiliar to me, but seems
> to be for a specific device.*
>


So thinking about this further, I'm pretty sure if you're using the BBG
specific Linux image, there should be a device tree file specifically for
the I2C grove connector. Again, I'm not sure how these pins are brought
out, and from which I2C peripheral, but it does make sense they have their
own device tree file for the I2C grove connector . . . So if you ls
/lib/firmware/ there should be a hint as to which device tree file you need
to load. Based on the names.

On Sun, Oct 18, 2015 at 1: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 two I2C device tree overlays which I
> can load. One generic I2C, and another which is unfamiliar to me, but seems
> to be for a specific device.
>
> From here you should be able to load the first dtbo file if you have the
> same on your board, and be able to use your I2C utilities. Do however keep
> in mind that I am completely unfamiliar with the BBG. So I do not know
> anything about the grove connectors, how they work, how they're connected
> to board, and all that. So before going off half cocked based on what I'm
> saying, you should double check what you can.
>
> But if you have further questions, I'd be glad to help. I do have interest
> in the BBG . . . But we already own 5 blacks . . .
>
> On Sun, Oct 18, 2015 at 12:25 PM, Ben Shapiro 
> 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
>>
>>
>> On Sunday, October 18, 2015 at 12:10:59 PM UTC-6, William Hermans wrote:
>>>
>>> Hi Ben,
>>>
>>> Have you resolved your issue yet ? Personally I have not used I2C on any
>>> Beaglebone yet. However I thought I might mention that for most ( perhaps
>>> all ) devices of this nature on the Beaglebone's you need to load a device
>>> tree file, which in turn often loads needed kernel module drivers, sets the
>>> pins up, etc.
>>>
>>> On Fri, Oct 16, 2015 at 10:12 AM, Ben Shapiro 
>>> wrote:
>>>
 (apologies if this is a double-post... my first submission does not
 seem to have gone through)

 Hi,

 I've been having a hell of a time getting the BeagleBone Green to see
 Grove devices connected to it.

 Running i2cdetect -r 0 results in the following output regardless of
 which Grove sensors are connected:

 # i2cdetect  -r 0
 WARNING! This program can confuse your I2C bus, cause data loss and
 worse!
 I will probe file /dev/i2c-0 using read byte commands.
 I will probe address range 0x03-0x77.
 Continue? [Y/n] y
  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 70: -- -- -- -- -- -- -- --

 Similarly, i2cdetect -r 1 always results in the following output:

 # i2cdetect  -r 1
 WARNING! This program can confuse your I2C bus, cause data loss and
 worse!
 I will probe file /dev/i2c-1 using read byte commands.
 I will probe address range 0x03-0x77.
 Continue? [Y/n] y
  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Re: [beagleboard] Transmit buffer underflow when trying to play audio using an externally attached codec board

[Rick Mann]

I've had the same problem with kernels later than 3.8. On 3.8, I switched to 
using ti,da830-evm-audio (davinci-evm.c, I think). My DTS (for both types of 
sound card) call for a 12MHz McASP master clock, but in 4.x kernels, I would 
actually see a 24MHz signal come off the master clock, and I think that's what 
led to the underflow.

FWIW, here's my DTS (for 3.8):


https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-BONE-AUDI-03-00A0.dts

I would love to get this to work in 4.1.x

> On Oct 18, 2015, at 07:46 , henni19...@googlemail.com wrote:
> 
> Hi,
> 
> I have the same problem.
> Which kernel are you using?
> I'm currently working with the offical BeagleBone 4.1 kernel.
> The only useful information I found is this post:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-November/083797.html
> "An underrun (playback) event occurs when the serializer transfer
> data from the XRBUF buffer to the XRSR shift register, but the
> XRBUF hasn't been filled. Similarly, the overrun (capture) event
> occurs when data from the XRSR shift register is transferred to
> the XRBUF but it hasn't been read yet."
> 
> So I think there is a problem with the mcasp interface and ASoC.
> 
> Am Montag, 10. August 2015 14:25:32 UTC+2 schrieb Shadi Abdu-Rahman:
> Hi all,
> 
> I'm having trouble using an audio codec board with a custom device tree 
> overlay (see below) with the Beaglebone Black. When exporting the overlay, 
> the codecs seem to register fine:
> 
> dmesg
> [ 1375.144463] bone_capemgr bone_capemgr: part_number 'BB-BONE-XA-SK-AU', 
> version 'N/A'
> [ 1375.152305] bone_capemgr bone_capemgr: slot #4: override
> [ 1375.157799] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
> [ 1375.164864] bone_capemgr bone_capemgr: slot #4: 'Override Board 
> Name,00A0,Override Manuf,BB-BONE-XA-SK-AU'
> [ 1375.206351] bone_capemgr bone_capemgr: slot #4: dtbo 
> 'BB-BONE-XA-SK-AU-00A0.dtbo' loaded; overlay id #0
> [ 1375.464260] cs4270 2-0048: found device at i2c address 48
> [ 1375.469699] cs4270 2-0048: hardware revision 3
> [ 1375.485782] cs4270 2-0049: found device at i2c address 49
> [ 1375.491222] cs4270 2-0049: hardware revision 3
> [ 1375.504744] (NULL device *): Setting gpio_int_masterclk_enable = 0
> [ 1375.513334] asoc-simple-card ocp:sound: cs4270-hifi <-> 48038000.mcasp 
> mapping ok
> [ 1375.521095] (NULL device *): Setting gpio_int_masterclk_enable = 0
> [ 1375.529893] asoc-simple-card ocp:sound: cs4270-hifi <-> 48038000.mcasp 
> mapping ok
> 
> aplay -l
>  List of PLAYBACK Hardware Devices 
> card 0: XMOSAudioSlice [XMOS-Audio-Slice], device 0: 
> davinci-mcasp.0-cs4270-hifi-a cs4270-hifi-0 []
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 0: XMOSAudioSlice [XMOS-Audio-Slice], device 1: 
> davinci-mcasp.0-cs4270-hifi-b cs4270-hifi-1 []
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> 
> lsmod:
> snd_soc_davinci_mcasp14391  2 
> snd_soc_simple_card 8156  0 
> snd_soc_edma1150  1 snd_soc_davinci_mcasp
> snd_soc_cs4270  6875  2 
> snd_soc_omap2573  1 snd_soc_davinci_mcasp
> snd_soc_core  156881  5 
> snd_soc_davinci_mcasp,snd_soc_edma,snd_soc_omap,snd_soc_simple_card,snd_soc_cs4270
> snd_compress   11668  1 snd_soc_core
> snd_pcm_dmaengine   5061  2 snd_soc_core,snd_soc_omap
> snd_pcm77081  4 
> snd_soc_davinci_mcasp,snd_soc_core,snd_soc_omap,snd_pcm_dmaengine
> snd_timer  16860  1 snd_pcm
> snd56902  4 snd_soc_core,snd_timer,snd_pcm,snd_compress
> soundcore   6869  1 snd
> pvrsrvkm  147014  0 
> omap_aes   13089  0 
> omap_sham  19190  0 
> tda998x11683  1 
> tilcdc 27919  0 
> omap_rng4354  0 
> rng_core7270  1 omap_rng
> drm_kms_helper106610  3 tda998x,tilcdc
> uio_pdrv_genirq 3317  0 
> leds_gpio   3102  0 
> uio 8330  1 uio_pdrv_genirq
> 
> but when I try to play an audio file I get a stream of transmit buffer 
> underflows and no audio:
> 
> aplay test128.wav
> Playing WAVE 'test128.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, 
> Stereo
> underrun!!! (at least 1.630 ms long)
> underrun!!! (at least 5.413 ms long)
> underrun!!! (at least 0.636 ms long)
> underrun!!! (at least 5.369 ms long)
> underrun!!! (at least 0.217 ms long)
> underrun!!! (at least 0.641 ms long)
> underrun!!! (at least 5.254 ms long)
> 
> dmesg
> [ 1493.190031] davinci-mcasp 48038000.mcasp: Transmit buffer underflow
> [ 1493.201647] davinci-mcasp 48038000.mcasp: Transmit buffer underflow
> [ 1493.218719] davinci-mcasp 48038000.mcasp: Transmit buffer underflow
> [ 1493.229946] davinci-mcasp 48038000.mcasp: Transmit buffer underflow
> [ 1493.245328] davinci-mcasp 48038000.mcasp: Transmit buffer underflow
> [ 1493.259411] davinci-mcasp 48038000.mcasp: Transmit buffer underflow
> [ 1493.270549] 

Re: [beagleboard] BeagleBone Green Grove i2c issues

[William Hermans]

My best guess is that I2C1 is brought out to the I2C connector, so enabling
BB-I2C1-00A0.dtbo should work for you.

On Sun, Oct 18, 2015 at 2:43 PM, Ben Shapiro 
wrote:

> Sadly, there does not seem to be a BBG-specific image.
>
>
>
> On Sunday, October 18, 2015 at 3:29:16 PM UTC-6, William Hermans wrote:
>>
>> *$ ls /lib/firmware/ | grep I2C*
>>> *BB-I2C1-00A0.dtbo*
>>> *BB-I2C1-PCA9685-00A0.dtbo*
>>>
>>> *Looks like, at least for me, I have two I2C device tree overlays which
>>> I can load. One generic I2C, and another which is unfamiliar to me, but
>>> seems to be for a specific device.*
>>>
>>
>>
>> So thinking about this further, I'm pretty sure if you're using the BBG
>> specific Linux image, there should be a device tree file specifically for
>> the I2C grove connector. Again, I'm not sure how these pins are brought
>> out, and from which I2C peripheral, but it does make sense they have their
>> own device tree file for the I2C grove connector . . . So if you ls
>> /lib/firmware/ there should be a hint as to which device tree file you need
>> to load. Based on the names.
>>
>> On Sun, Oct 18, 2015 at 1: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 two I2C device tree overlays which I
>>> can load. One generic I2C, and another which is unfamiliar to me, but seems
>>> to be for a specific device.
>>>
>>> From here you should be able to load the first dtbo file if you have the
>>> same on your board, and be able to use your I2C utilities. Do however keep
>>> in mind that I am completely unfamiliar with the BBG. So I do not know
>>> anything about the grove connectors, how they work, how they're connected
>>> to board, and all that. So before going off half cocked based on what I'm
>>> saying, you should double check what you can.
>>>
>>> But if you have further questions, I'd be glad to help. I do have
>>> interest in the BBG . . . But we already own 5 blacks . . .
>>>
>>> On Sun, Oct 18, 2015 at 12:25 PM, Ben Shapiro 
>>> 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


 On Sunday, October 18, 2015 at 12:10:59 PM UTC-6, William Hermans wrote:
>
> Hi Ben,
>
> Have you resolved your issue yet ? Personally I have not used I2C on
> any Beaglebone yet. However I thought I might mention that for most (
> perhaps all ) devices of this nature on the Beaglebone's you need to load 
> a
> device tree file, which in turn often loads needed kernel module drivers,
> sets the pins up, etc.
>
> On Fri, Oct 16, 2015 at 10:12 AM, Ben Shapiro 
> wrote:
>
>> (apologies if this is a double-post... my first submission does not
>> seem to have gone through)
>>
>> Hi,
>>
>> I've been having a hell of a time getting the BeagleBone Green to see
>> Grove devices connected to it.
>>
>> Running i2cdetect -r 0 results in the following output regardless of
>> which Grove sensors are connected:
>>
>> # i2cdetect  -r 0
>> WARNING! This program can confuse your I2C bus, cause data loss and
>> worse!
>> I will probe file /dev/i2c-0 using read byte commands.
>> I will probe address range 0x03-0x77.
>> Continue? [Y/n] y
>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Re: [beagleboard] BeagleBone Green Grove i2c issues

[William Hermans]

No luck yet ? I'm doing more investigating . . . so what is the output of
the command:

$ cat /etc/dogtag

?

If your Linux image predates Aug 11 this year, and you've not recently
updated your device tree file binaries. Then loading the current
BB-I2C1-00A0.dtbo may not work. If we notice the difference between:

https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-I2C1-00A0.dts
and
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C1-00A0.dts

We have the difference between:

*compatible = "ti,beaglebone", "ti,beaglebone-black"; *
and


*compatible = "ti,beaglebone", "ti,beaglebone-black",
"ti,beaglebone-green";*
This would be a good indication as to why. Anyway, I'm hoping this is
helping more than confusing . . .

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

> My best guess is that I2C1 is brought out to the I2C connector, so
> enabling BB-I2C1-00A0.dtbo should work for you.
>
> On Sun, Oct 18, 2015 at 2:43 PM, Ben Shapiro 
> wrote:
>
>> Sadly, there does not seem to be a BBG-specific image.
>>
>>
>>
>> On Sunday, October 18, 2015 at 3:29:16 PM UTC-6, William Hermans wrote:
>>>
>>> *$ ls /lib/firmware/ | grep I2C*
 *BB-I2C1-00A0.dtbo*
 *BB-I2C1-PCA9685-00A0.dtbo*

 *Looks like, at least for me, I have two I2C device tree overlays which
 I can load. One generic I2C, and another which is unfamiliar to me, but
 seems to be for a specific device.*

>>>
>>>
>>> So thinking about this further, I'm pretty sure if you're using the BBG
>>> specific Linux image, there should be a device tree file specifically for
>>> the I2C grove connector. Again, I'm not sure how these pins are brought
>>> out, and from which I2C peripheral, but it does make sense they have their
>>> own device tree file for the I2C grove connector . . . So if you ls
>>> /lib/firmware/ there should be a hint as to which device tree file you need
>>> to load. Based on the names.
>>>
>>> On Sun, Oct 18, 2015 at 1: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 two I2C device tree overlays which
 I can load. One generic I2C, and another which is unfamiliar to me, but
 seems to be for a specific device.

 From here you should be able to load the first dtbo file if you have
 the same on your board, and be able to use your I2C utilities. Do however
 keep in mind that I am completely unfamiliar with the BBG. So I do not know
 anything about the grove connectors, how they work, how they're connected
 to board, and all that. So before going off half cocked based on what I'm
 saying, you should double check what you can.

 But if you have further questions, I'd be glad to help. I do have
 interest in the BBG . . . But we already own 5 blacks . . .

 On Sun, Oct 18, 2015 at 12:25 PM, Ben Shapiro 
 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
>
>
> On Sunday, October 18, 2015 at 12:10:59 PM UTC-6, William Hermans
> wrote:
>>
>> Hi Ben,
>>
>> Have you resolved your issue yet ? Personally I have not used I2C on
>> any Beaglebone yet. However I thought I might mention that for most (
>> perhaps all ) devices of this nature on the Beaglebone's you need to 
>> load a
>> device tree file, which in turn often loads needed kernel module drivers,
>> sets the pins up, etc.
>>
>> On Fri, Oct 16, 2015 at 10:12 AM, Ben Shapiro 
>> wrote:
>>
>>> (apologies if this is a double-post... my first submission does not
>>> seem to have gone through)
>>>
>>> Hi,

[beagleboard] Status of pruss in 4.1.10-ti-r21/2015-10-11 Debian snapshot?

[Rick Mann]

Pruss is still broken in the 4.1.10-ti-r21 kernel, right?

Does anyone know if the new remoteproc thing can be used to download existing 
firmware that was built with pruss in mind, and how I could modify my code to 
use that instead?

Thanks,

-- 
Rick Mann
rm...@latencyzero.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] Status of pruss in 4.1.10-ti-r21/2015-10-11 Debian snapshot?

[Rick Mann]

> On Oct 18, 2015, at 17:11 , Robert Nelson  wrote:
> 
> On Sun, Oct 18, 2015 at 7:05 PM, Rick Mann  wrote:
>> Pruss is still broken in the 4.1.10-ti-r21 kernel, right?
>> 
>> Does anyone know if the new remoteproc thing can be used to download 
>> existing firmware that was built with pruss in mind, and how I could modify 
>> my code to use that instead?
>> 
> 
> another user got it working with remoteproc, he's just waiting for a
> beta-x15 to arrive so that they will work the same on both boards..

Oh, do you remember who that was?

-- 
Rick Mann
rm...@latencyzero.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] Transmit buffer underflow when trying to play audio using an externally attached codec board

[William Hermans]

"buffer underflow", heh sounds a bit like an oxy- moron, . . .

On Sun, Oct 18, 2015 at 6:58 PM, Rick Mann  wrote:

> I've had the same problem with kernels later than 3.8. On 3.8, I switched
> to using ti,da830-evm-audio (davinci-evm.c, I think). My DTS (for both
> types of sound card) call for a 12MHz McASP master clock, but in 4.x
> kernels, I would actually see a 24MHz signal come off the master clock, and
> I think that's what led to the underflow.
>
> FWIW, here's my DTS (for 3.8):
>
>
> https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-BONE-AUDI-03-00A0.dts
>
> I would love to get this to work in 4.1.x
>
> > On Oct 18, 2015, at 07:46 , henni19...@googlemail.com wrote:
> >
> > Hi,
> >
> > I have the same problem.
> > Which kernel are you using?
> > I'm currently working with the offical BeagleBone 4.1 kernel.
> > The only useful information I found is this post:
> >
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-November/083797.html
> > "An underrun (playback) event occurs when the serializer transfer
> > data from the XRBUF buffer to the XRSR shift register, but the
> > XRBUF hasn't been filled. Similarly, the overrun (capture) event
> > occurs when data from the XRSR shift register is transferred to
> > the XRBUF but it hasn't been read yet."
> >
> > So I think there is a problem with the mcasp interface and ASoC.
> >
> > Am Montag, 10. August 2015 14:25:32 UTC+2 schrieb Shadi Abdu-Rahman:
> > Hi all,
> >
> > I'm having trouble using an audio codec board with a custom device tree
> overlay (see below) with the Beaglebone Black. When exporting the overlay,
> the codecs seem to register fine:
> >
> > dmesg
> > [ 1375.144463] bone_capemgr bone_capemgr: part_number
> 'BB-BONE-XA-SK-AU', version 'N/A'
> > [ 1375.152305] bone_capemgr bone_capemgr: slot #4: override
> > [ 1375.157799] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 4
> > [ 1375.164864] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,BB-BONE-XA-SK-AU'
> > [ 1375.206351] bone_capemgr bone_capemgr: slot #4: dtbo
> 'BB-BONE-XA-SK-AU-00A0.dtbo' loaded; overlay id #0
> > [ 1375.464260] cs4270 2-0048: found device at i2c address 48
> > [ 1375.469699] cs4270 2-0048: hardware revision 3
> > [ 1375.485782] cs4270 2-0049: found device at i2c address 49
> > [ 1375.491222] cs4270 2-0049: hardware revision 3
> > [ 1375.504744] (NULL device *): Setting gpio_int_masterclk_enable = 0
> > [ 1375.513334] asoc-simple-card ocp:sound: cs4270-hifi <->
> 48038000.mcasp mapping ok
> > [ 1375.521095] (NULL device *): Setting gpio_int_masterclk_enable = 0
> > [ 1375.529893] asoc-simple-card ocp:sound: cs4270-hifi <->
> 48038000.mcasp mapping ok
> >
> > aplay -l
> >  List of PLAYBACK Hardware Devices 
> > card 0: XMOSAudioSlice [XMOS-Audio-Slice], device 0:
> davinci-mcasp.0-cs4270-hifi-a cs4270-hifi-0 []
> >   Subdevices: 1/1
> >   Subdevice #0: subdevice #0
> > card 0: XMOSAudioSlice [XMOS-Audio-Slice], device 1:
> davinci-mcasp.0-cs4270-hifi-b cs4270-hifi-1 []
> >   Subdevices: 1/1
> >   Subdevice #0: subdevice #0
> >
> > lsmod:
> > snd_soc_davinci_mcasp14391  2
> > snd_soc_simple_card 8156  0
> > snd_soc_edma1150  1 snd_soc_davinci_mcasp
> > snd_soc_cs4270  6875  2
> > snd_soc_omap2573  1 snd_soc_davinci_mcasp
> > snd_soc_core  156881  5
> snd_soc_davinci_mcasp,snd_soc_edma,snd_soc_omap,snd_soc_simple_card,snd_soc_cs4270
> > snd_compress   11668  1 snd_soc_core
> > snd_pcm_dmaengine   5061  2 snd_soc_core,snd_soc_omap
> > snd_pcm77081  4
> snd_soc_davinci_mcasp,snd_soc_core,snd_soc_omap,snd_pcm_dmaengine
> > snd_timer  16860  1 snd_pcm
> > snd56902  4
> snd_soc_core,snd_timer,snd_pcm,snd_compress
> > soundcore   6869  1 snd
> > pvrsrvkm  147014  0
> > omap_aes   13089  0
> > omap_sham  19190  0
> > tda998x11683  1
> > tilcdc 27919  0
> > omap_rng4354  0
> > rng_core7270  1 omap_rng
> > drm_kms_helper106610  3 tda998x,tilcdc
> > uio_pdrv_genirq 3317  0
> > leds_gpio   3102  0
> > uio 8330  1 uio_pdrv_genirq
> >
> > but when I try to play an audio file I get a stream of transmit buffer
> underflows and no audio:
> >
> > aplay test128.wav
> > Playing WAVE 'test128.wav' : Signed 16 bit Little Endian, Rate 48000 Hz,
> Stereo
> > underrun!!! (at least 1.630 ms long)
> > underrun!!! (at least 5.413 ms long)
> > underrun!!! (at least 0.636 ms long)
> > underrun!!! (at least 5.369 ms long)
> > underrun!!! (at least 0.217 ms long)
> > underrun!!! (at least 0.641 ms long)
> > underrun!!! (at least 5.254 ms long)
> >
> > dmesg
> > [ 1493.190031] davinci-mcasp 48038000.mcasp: Transmit buffer underflow
> > [ 1493.201647] davinci-mcasp 48038000.mcasp: Transmit buffer underflow
> > [ 1493.218719] 

[beagleboard] Re: Poor Java performance on new BBB

[Fohnbit]

Hallo!

Ok, but can I change the Kernel from the slow BBB without reflash the whole 
system with a new Image?

-- 
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] Reserving memory for writes to DDR from PRUs

[William Hermans]

What you need to do. Is understand how "things" are mapped into memory. So
from the gist of things, It sounds like you're creeping into memory
reserved by "something else". NO one can tell, as you've not given us any
code . . .

On Sun, Oct 18, 2015 at 6:42 PM, Andrew Szymkowiak  wrote:

> For my application, I want to write from the PRU into a large set of
> circular buffers in the ARM DDR memory.  Following various examples, I have
> gotten this to work for small amounts of data, but when I attempt to write
> "too much", I crash the Linux.  To me, this is not surprising, as I don't
> see where the Linux has been warned to set aside the memory region where
> the data from the PRU will be appearing.  Should I be booting with some
> options like "MEMMAP=" being passed in the kernel parameters?  (This is a
> concept I'm slightly familiar with from the X86 arch). Does anyone have any
> successful examples of having done this? (Is MEMMAP the way to do it?  Or
> is there perhaps something I need to add to the pruss section of the
> devtree?)
>
> To add some more details, I've tried expanding the "extram_pool_sz" option
> when I modprobe in the uio_pruss driver, but get crashes way before I
> approach the size  (which I have verified with a call to
> prussdrv_extmem_size()).  I've looked at the source for the prussdrv side,
> and for the uio_pruss driver, and don't see where memory is ever reserved
> or locked down.  Also, I've never seen the data at the pointer returned
> from calling prussdrv_map_extmem, but had to mmap into /dev/mem myself
> (following examples I found w/ Google).
>
> Thanks,
>Andy S.
>
> --
> 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] SPI's Beginner Guide

[William Hermans]

>
> *Hi,*
>
> *testing different kind of sensors/modules provide the change to work with
the several buses the BeagleBone Black has.*


Irreverent . . .

*Now, I'm playing with an analog light sensor connected to an ADC which
> communicate with BBB through SPI bus. *
> *So, the first step I need to do is enable the SPI. Then, test SPI with
> loopback example. And finally, build the code to read from the ADC the
> light sensor data.*
>

The first thing you need to do, is understand how your device works. Which
is regardless to how / what SPI *is*.

*To enable SPI0, I have followed this guide, SPIDEV
> . During the guide steps
> implementation I have found some doubts/issues, so I will explain the
> procedure I has followed with its results in order to get the more precise
> help as possible.*
>
-

*Create and Edit: BB-SPI0-01-00A0.dts*


Excuse me, What ?!

Ok, first of all, what you need to understand is what SPI *is*. Passed
that, you need to understand how to communicate with your device *over*
SPI. After that, if you still have questions about SPIdev, I'm sure someone
will be glad to help.







>


On Fri, Oct 16, 2015 at 4:30 AM,  wrote:

> Hi,
>
> testing different kind of sensors/modules provide the change to work with
> the several buses the BeagleBone Black has.
>
> Now, I'm playing with an analog light sensor connected to an ADC which
> communicate with BBB through SPI bus.
> So, the first step I need to do is enable the SPI. Then, test SPI with
> loopback example. And finally, build the code to read from the ADC the
> light sensor data.
>
> BeagleBone Black has:
>
>- OS: Debian
>- Kernel: 3.8.13-bone78
>- Kernel version: #1 SMP Sat Sep 26 09:11:50 UTC 2015
>
> To enable SPI0, I have followed this guide, SPIDEV
> . During the guide
> steps implementation I have found some doubts/issues, so I will explain the
> procedure I has followed with its results in order to get the more precise
> help as possible.
>
>1. Create and Edit: *BB-SPI0-01-00A0.dts*
>2. Compile: *BB-SPI0-01-00A0.dts*
>3. Copy, *BB-SPI0-01-00A0.dtbo*, to: */lib/firmware/*
>4. Enable the Device Overlay Tree:
>   - *echo BB-SPI0-01 > /sys/devices/bone_capemgr.*/slots*
>   - At my system '*' is '9'.
>   5. Edit: */boot/uboot/uEnv.txt* file to add next line:
>   - *optargs=quiet drm.debug=7 capemgr.enable_partno=BB-SPI0-01*
>   6. Reboot.
>7. List SPI buses enabled: *ls -al /dev/spidev0.**
>   - *ISSUE1*: there is no SPI bus enabled. I need to repeat the step
>   4 to finally enabled the SPI bus. So, I have added that line to 
> '.profile'
>   to have SPI enabled with every bootup. Is there any mistake at this
>   behaviour?
>8. Show pingroups:
>   - *cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups*
>   1. group: spi0_pins_s0
>  2. pin 84 (44e10950)
>  3. pin 85 (44e10954)
>  4. pin 86 (44e10958)
>  5. pin 87 (44e1095c)
>  - *QUESTION1*: How can I find out which address correspond to a
>   pin? I tried to find it at BBB_SRM but there is no info about.
>
>
> Now, it is time to check SPI running a loopback example. The SPIDEV
>  guide tells to shorcut
> pins 29 & 30 for SPI1, so for SPI0 pins are 18 & 21.
> But, here start new problems:
>
>1. Next step ask for apply *diff to the kernel*.
>   - *diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c*
>   - Output: diff: unrecognized option '--git'
>  - *ISSUE2*: Moreover, there is no spidev.c at BBB system. No
>  diff can be made.
>   2. Finally, test the SPI with '*spidev_test*' program.
>   - *QUESTION2*: Where is that file? Or the path,
>   *kernel/Documentation/spi*?
>
>
> Well, once we reach this point there is only one thing more I would like
> to know. If I write a new code to work with SPI & sensors, *which
> libraries should be added*? (Maybe, <*linux/spi/spidev.h*> will be
> enough).
>
> Kind Regards.
>
> --
> 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.

[beagleboard] barematel assembly level programming with jtag

[Peter Cheung]

Hi
   How to do barematel assembly level programming with jtag? In the webpage 
i see it built in jtag, but can't find further information.
thanks
from Peter (cmk...@hotmail.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

[Ben Shapiro]

Sadly, there does not seem to be a BBG-specific image.



On Sunday, October 18, 2015 at 3:29:16 PM UTC-6, William Hermans wrote:
>
> *$ ls /lib/firmware/ | grep I2C*
>> *BB-I2C1-00A0.dtbo*
>> *BB-I2C1-PCA9685-00A0.dtbo*
>>
>> *Looks like, at least for me, I have two I2C device tree overlays which I 
>> can load. One generic I2C, and another which is unfamiliar to me, but seems 
>> to be for a specific device.*
>>
>
>
> So thinking about this further, I'm pretty sure if you're using the BBG 
> specific Linux image, there should be a device tree file specifically for 
> the I2C grove connector. Again, I'm not sure how these pins are brought 
> out, and from which I2C peripheral, but it does make sense they have their 
> own device tree file for the I2C grove connector . . . So if you ls 
> /lib/firmware/ there should be a hint as to which device tree file you need 
> to load. Based on the names.
>
> On Sun, Oct 18, 2015 at 1: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 two I2C device tree overlays which I 
>> can load. One generic I2C, and another which is unfamiliar to me, but seems 
>> to be for a specific device.
>>
>> From here you should be able to load the first dtbo file if you have the 
>> same on your board, and be able to use your I2C utilities. Do however keep 
>> in mind that I am completely unfamiliar with the BBG. So I do not know 
>> anything about the grove connectors, how they work, how they're connected 
>> to board, and all that. So before going off half cocked based on what I'm 
>> saying, you should double check what you can.
>>
>> But if you have further questions, I'd be glad to help. I do have 
>> interest in the BBG . . . But we already own 5 blacks . . .
>>
>> On Sun, Oct 18, 2015 at 12:25 PM, Ben Shapiro > > 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
>>>
>>>
>>> On Sunday, October 18, 2015 at 12:10:59 PM UTC-6, William Hermans wrote:

 Hi Ben,

 Have you resolved your issue yet ? Personally I have not used I2C on 
 any Beaglebone yet. However I thought I might mention that for most ( 
 perhaps all ) devices of this nature on the Beaglebone's you need to load 
 a 
 device tree file, which in turn often loads needed kernel module drivers, 
 sets the pins up, etc.

 On Fri, Oct 16, 2015 at 10:12 AM, Ben Shapiro  
 wrote:

> (apologies if this is a double-post... my first submission does not 
> seem to have gone through)
>
> Hi,
>
> I've been having a hell of a time getting the BeagleBone Green to see 
> Grove devices connected to it. 
>
> Running i2cdetect -r 0 results in the following output regardless of 
> which Grove sensors are connected: 
>
> # i2cdetect  -r 0
> WARNING! This program can confuse your I2C bus, cause data loss and 
> worse!
> I will probe file /dev/i2c-0 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> Similarly, i2cdetect -r 1 always results in the following output: 
>
> # i2cdetect  -r 1
> WARNING! This program can confuse your I2C bus, cause data loss and 
> worse!
> I will probe file /dev/i2c-1 using read 

Re: [beagleboard] BeagleBone Green Grove i2c issues

[Robert Nelson]

On Sun, Oct 18, 2015 at 6:47 PM, Robert Nelson  wrote:
> Make sure you have it connected to the correct Grove connector, one is
> i2c2 (same bus as the "cape eeprom") the other is usart2...

I should also mention... Full support for the Green is with these images:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots

The initial seeed image just used the black for green... As it's 99%
compatiable...

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] Kernel 4.1.9 overlays not working

[codemonkey]

Robert, I have the same question about the source of DTC 1.4.1-gXYZXYZXYZ - 
I installed the device-tree-overlay package into a new build (Linux 
beaglebone 4.1.10-bone-rt-r16 #1 Sun Oct 4 09:05:14 UTC 2015 armv7l 
GNU/Linux) and checked the version of dtc. It was v1.4.0. I tried running 
./dtc_overlay.sh, but the version didn't change. So, I cloned the git 
repository of the source at devicetree.org, did a make and make install. 
The version is still 1.4.0. The only reference Google has to the string in 
your readme (DTC 1.4.1-gXYZXYZXYZ) points to your readme. 

Thank you
Tim

On Tuesday, October 13, 2015 at 8:23:00 AM UTC-7, RobertCNelson wrote:
>
> On Tue, Oct 13, 2015 at 10:20 AM, Lee Armstrong  > wrote: 
> > Thanks Robert, 
> > 
> > I’ve just reflashed it again with the latest Jessie image and will run 
> > through those steps. 
> > 
> > One thing not 100% clear in the steps is the best location to get the 
> latest 
> > (patched) DTC, there are many differing sources it seems! 
>
> I moved the "./dtc-overlay.sh" script right after the "check dtc" in 
> step 2... I'm hoping it should be more obvious to run it.. 
>
> 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.

[beagleboard] Reserving memory for writes to DDR from PRUs

[Andrew Szymkowiak]

For my application, I want to write from the PRU into a large set of 
circular buffers in the ARM DDR memory.  Following various examples, I have 
gotten this to work for small amounts of data, but when I attempt to write 
"too much", I crash the Linux.  To me, this is not surprising, as I don't 
see where the Linux has been warned to set aside the memory region where 
the data from the PRU will be appearing.  Should I be booting with some 
options like "MEMMAP=" being passed in the kernel parameters?  (This is a 
concept I'm slightly familiar with from the X86 arch). Does anyone have any 
successful examples of having done this? (Is MEMMAP the way to do it?  Or 
is there perhaps something I need to add to the pruss section of the 
devtree?) 

To add some more details, I've tried expanding the "extram_pool_sz" option 
when I modprobe in the uio_pruss driver, but get crashes way before I 
approach the size  (which I have verified with a call to 
prussdrv_extmem_size()).  I've looked at the source for the prussdrv side, 
and for the uio_pruss driver, and don't see where memory is ever reserved 
or locked down.  Also, I've never seen the data at the pointer returned 
from calling prussdrv_map_extmem, but had to mmap into /dev/mem myself 
(following examples I found w/ Google).

Thanks,
   Andy S.

-- 
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] xenomai boot on beaglebone debian 2015 image SD card: how ?

[Matteo Loda]

Thank you very much William !

Robert you are more real time than a real time kernel ^^

I will try both the way and I will tell you the results

Have a nice Sunday Evening :)

Matt





2015-10-18 19:13 GMT+02:00 Robert Nelson :

>
> On Oct 18, 2015 10:08 AM, "Matteo Loda"  wrote:
> >
> > Hi guys
> >
> > I try to send again this topic , so if this is a duplicate I apologize
> >
> > I am following this
> guide: installing-xenomai-on-beaglebone-using-debian-distribution
> >
> > They use a bone-debian-7.5-2014-05-14-2gb.img.xz.
> >
> > So they have two partition on the SD card Image
> >
> > 1) boot partition with zImage files ,they change  original debian zImage
> with xenomai zImage
> > 2) rootfs partition
> >
> > I try to use a 2015 debian image: bone-debian-7.8-2015-03-01-2gb.img.xz
> >
> > But I have only a single partition , with a boot folder, in which I have
> no zImage
> >
> > So how could I boot xenomai ?
> >
> > I followed another way: build an image.
> >
> > I tryed the github.com/beagleboard/image-builder form RobertCNelson ,
> but I obtain, with a 2015 image, a single SD partition.
> >
> > Could you tell me how to configure image-builder to build a separated
> boot partition with the image-builder ? ( 2015 debian image 3.8 kernel)
>
> Pre built image is available here:
>
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29_Machinekit
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/5HDjgE4r-9U/unsubscribe.
> To unsubscribe from this group and all its topics, 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] BeagleBone Green Grove i2c issues

[Ben Shapiro]

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


On Sunday, October 18, 2015 at 12:10:59 PM UTC-6, William Hermans wrote:
>
> Hi Ben,
>
> Have you resolved your issue yet ? Personally I have not used I2C on any 
> Beaglebone yet. However I thought I might mention that for most ( perhaps 
> all ) devices of this nature on the Beaglebone's you need to load a device 
> tree file, which in turn often loads needed kernel module drivers, sets the 
> pins up, etc.
>
> On Fri, Oct 16, 2015 at 10:12 AM, Ben Shapiro  > wrote:
>
>> (apologies if this is a double-post... my first submission does not seem 
>> to have gone through)
>>
>> Hi,
>>
>> I've been having a hell of a time getting the BeagleBone Green to see 
>> Grove devices connected to it. 
>>
>> Running i2cdetect -r 0 results in the following output regardless of 
>> which Grove sensors are connected: 
>>
>> # i2cdetect  -r 0
>> WARNING! This program can confuse your I2C bus, cause data loss and worse!
>> I will probe file /dev/i2c-0 using read byte commands.
>> I will probe address range 0x03-0x77.
>> Continue? [Y/n] y
>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 70: -- -- -- -- -- -- -- --
>>
>> Similarly, i2cdetect -r 1 always results in the following output: 
>>
>> # i2cdetect  -r 1
>> WARNING! This program can confuse your I2C bus, cause data loss and worse!
>> I will probe file /dev/i2c-1 using read byte commands.
>> I will probe address range 0x03-0x77.
>> Continue? [Y/n] y
>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 70: -- -- -- -- -- -- -- --
>>
>> I tried reflashing my board with the 2015-07-28 eMMC Flasher (console) 
>> image. My current uname -a output is: Linux greenbone 3.8.13-bone72 #1 
>> SMP Tue Jun 16 21:36:04 UTC 2015 armv7l GNU/Linux. 
>> However, flashing did not help. 
>>
>> I also tried on a second board. Same problem. 
>> The BBG Alarm System code 
>>  posted on the BBG 
>> product page also will not run. 
>>
>> Am I doing something wrong? 
>>
>> Thank you, 
>> Ben 
>>
>>
>>
>>
>> -- 
>> 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.
>>
>
>

-- 
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] xenomai boot on beaglebone debian 2015 image SD card: how ?

[Matteo Loda]

Hi guys

I try to send again this topic , so if this is a duplicate I apologize

I am following this guide: 
installing-xenomai-on-beaglebone-using-debian-distribution 


They use a bone-debian-7.5-2014-05-14-2gb.img.xz.

So they have two partition on the SD card Image

1) boot partition with zImage files ,they change  original debian zImage 
with xenomai zImage
2) rootfs partition

I try to use a 2015 debian image: bone-debian-7.8-2015-03-01-2gb.img.xz

But I have only a single partition , with a boot folder, in which I have no 
zImage 

So how could I boot xenomai ?  

I followed another way: build an image.

I tryed the github.com/beagleboard/image-builder form RobertCNelson , but I 
obtain, with a 2015 image, a single SD partition.

Could you tell me how to configure image-builder to build a separated boot 
partition with the image-builder ? ( 2015 debian image 3.8 kernel)

Thanks a lot.

Matt

-- 
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] xenomai boot on beaglebone debian 2015 image SD card: how ?

[William Hermans]

$ sudo apt-get update
$ sudo apt-cache search linux-image |grep xenomai
. . .
linux-image-3.8.13-xenomai-r67 - Linux kernel, version 3.8.13-xenomai-r67
linux-image-3.8.13-xenomai-r69 - Linux kernel, version 3.8.13-xenomai-r69
linux-image-3.8.13-xenomai-r70 - Linux kernel, version 3.8.13-xenomai-r70
linux-image-3.8.13-xenomai-r71 - Linux kernel, version 3.8.13-xenomai-r71
linux-image-3.8.13-xenomai-r72 - Linux kernel, version 3.8.13-xenomai-r72
linux-image-3.8.13-xenomai-r76 - Linux kernel, version 3.8.13-xenomai-r76
linux-image-3.8.13-xenomai-r78 - Linux kernel, version 3.8.13-xenomai-r78

To install:
$ sudo apt-get install linux-image-3.8.13-xenomai-rxx

^^ much easier


On Sun, Oct 18, 2015 at 8:08 AM, Matteo Loda  wrote:

> Hi guys
>
> I try to send again this topic , so if this is a duplicate I apologize
>
> I am following this guide:
> installing-xenomai-on-beaglebone-using-debian-distribution
> 
>
> They use a bone-debian-7.5-2014-05-14-2gb.img.xz.
>
> So they have two partition on the SD card Image
>
> 1) boot partition with zImage files ,they change  original debian zImage
> with xenomai zImage
> 2) rootfs partition
>
> I try to use a 2015 debian image: bone-debian-7.8-2015-03-01-2gb.img.xz
>
> But I have only a single partition , with a boot folder, in which I have
> no zImage
>
> So how could I boot xenomai ?
>
> I followed another way: build an image.
>
> I tryed the github.com/beagleboard/image-builder form RobertCNelson , but
> I obtain, with a 2015 image, a single SD partition.
>
> Could you tell me how to configure image-builder to build a separated boot
> partition with the image-builder ? ( 2015 debian image 3.8 kernel)
>
> Thanks a lot.
>
> Matt
>
> --
> 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] xenomai boot on beaglebone debian 2015 image SD card: how ?

[William Hermans]

Oh, and right, once installed, reboot the board ;)

On Sun, Oct 18, 2015 at 8:27 AM, William Hermans  wrote:

> $ sudo apt-get update
> $ sudo apt-cache search linux-image |grep xenomai
> . . .
> linux-image-3.8.13-xenomai-r67 - Linux kernel, version 3.8.13-xenomai-r67
> linux-image-3.8.13-xenomai-r69 - Linux kernel, version 3.8.13-xenomai-r69
> linux-image-3.8.13-xenomai-r70 - Linux kernel, version 3.8.13-xenomai-r70
> linux-image-3.8.13-xenomai-r71 - Linux kernel, version 3.8.13-xenomai-r71
> linux-image-3.8.13-xenomai-r72 - Linux kernel, version 3.8.13-xenomai-r72
> linux-image-3.8.13-xenomai-r76 - Linux kernel, version 3.8.13-xenomai-r76
> linux-image-3.8.13-xenomai-r78 - Linux kernel, version 3.8.13-xenomai-r78
>
> To install:
> $ sudo apt-get install linux-image-3.8.13-xenomai-rxx
>
> ^^ much easier
>
>
> On Sun, Oct 18, 2015 at 8:08 AM, Matteo Loda  wrote:
>
>> Hi guys
>>
>> I try to send again this topic , so if this is a duplicate I apologize
>>
>> I am following this guide:
>> installing-xenomai-on-beaglebone-using-debian-distribution
>> 
>>
>> They use a bone-debian-7.5-2014-05-14-2gb.img.xz.
>>
>> So they have two partition on the SD card Image
>>
>> 1) boot partition with zImage files ,they change  original debian zImage
>> with xenomai zImage
>> 2) rootfs partition
>>
>> I try to use a 2015 debian image: bone-debian-7.8-2015-03-01-2gb.img.xz
>>
>> But I have only a single partition , with a boot folder, in which I have
>> no zImage
>>
>> So how could I boot xenomai ?
>>
>> I followed another way: build an image.
>>
>> I tryed the github.com/beagleboard/image-builder form RobertCNelson ,
>> but I obtain, with a 2015 image, a single SD partition.
>>
>> Could you tell me how to configure image-builder to build a separated
>> boot partition with the image-builder ? ( 2015 debian image 3.8 kernel)
>>
>> Thanks a lot.
>>
>> Matt
>>
>> --
>> 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] BeagleBone Green Grove i2c issues

[William Hermans]

Hi Ben,

Have you resolved your issue yet ? Personally I have not used I2C on any
Beaglebone yet. However I thought I might mention that for most ( perhaps
all ) devices of this nature on the Beaglebone's you need to load a device
tree file, which in turn often loads needed kernel module drivers, sets the
pins up, etc.

On Fri, Oct 16, 2015 at 10:12 AM, Ben Shapiro 
wrote:

> (apologies if this is a double-post... my first submission does not seem
> to have gone through)
>
> Hi,
>
> I've been having a hell of a time getting the BeagleBone Green to see
> Grove devices connected to it.
>
> Running i2cdetect -r 0 results in the following output regardless of
> which Grove sensors are connected:
>
> # i2cdetect  -r 0
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-0 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> Similarly, i2cdetect -r 1 always results in the following output:
>
> # i2cdetect  -r 1
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-1 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> I tried reflashing my board with the 2015-07-28 eMMC Flasher (console)
> image. My current uname -a output is: Linux greenbone 3.8.13-bone72 #1
> SMP Tue Jun 16 21:36:04 UTC 2015 armv7l GNU/Linux.
> However, flashing did not help.
>
> I also tried on a second board. Same problem.
> The BBG Alarm System code
>  posted on the BBG
> product page also will not run.
>
> Am I doing something wrong?
>
> Thank you,
> Ben
>
>
>
>
> --
> 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] xenomai boot on beaglebone debian 2015 image SD card: how ?

[Robert Nelson]

On Oct 18, 2015 10:08 AM, "Matteo Loda"  wrote:
>
> Hi guys
>
> I try to send again this topic , so if this is a duplicate I apologize
>
> I am following this
guide: installing-xenomai-on-beaglebone-using-debian-distribution
>
> They use a bone-debian-7.5-2014-05-14-2gb.img.xz.
>
> So they have two partition on the SD card Image
>
> 1) boot partition with zImage files ,they change  original debian zImage
with xenomai zImage
> 2) rootfs partition
>
> I try to use a 2015 debian image: bone-debian-7.8-2015-03-01-2gb.img.xz
>
> But I have only a single partition , with a boot folder, in which I have
no zImage
>
> So how could I boot xenomai ?
>
> I followed another way: build an image.
>
> I tryed the github.com/beagleboard/image-builder form RobertCNelson , but
I obtain, with a 2015 image, a single SD partition.
>
> Could you tell me how to configure image-builder to build a separated
boot partition with the image-builder ? ( 2015 debian image 3.8 kernel)

Pre built image is available here:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29_Machinekit

-- 
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.