Re: [beagleboard] Re: Beaglebone Black Rebooting Several Times Every Day

[Thomas Olofsson]

Well new and interesting discoveries on this problem.

Last night we set up 9 bbw as well as the blacks for control. during the
night all of the bbb has crashed at least once and none of the bbw. All
running the same kernel and software. 3.15.2-bone5.

This means that this is hw related on the bbb board. i am starting to
suspect the PMIC that some interference somehow triggers a sys_reset. we
are trying to connect a data logger to some pins on the bbb to see if
sys_reset goes low prior to reboot but i strongly suspects it does..

--Skjortan!

On Tue, Sep 16, 2014 at 7:01 PM, Gerald Coley 
wrote:

> Thank you!
>
> Gerald
>
> On Tue, Sep 16, 2014 at 12:59 PM, Robert Nelson 
> wrote:
>
>> On Tue, Sep 16, 2014 at 12:56 PM, Gerald Coley 
>> wrote:
>> > Well. That would be nice to have everywhere.
>>
>> It is all the "bone" branches, except in the new 3.14-ti tree...  It
>> was one of those, I was just tagging a new release, oh crap, should
>> have added that. But was in a race to leave work today to run some
>> errands. ;)  It'll be the first thing i add back later.
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> http://www.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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/vgeh336p0P4/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] Custom Audio cape with TLV320AIC3107 codec.

[Jesse Cobra]

Have the schematic posted somewhere?
Versus this one: http://elinux.org/images/1/11/Audio_Cape_B1_Schematic.pdf


On Tue, Sep 16, 2014 at 9:09 PM, Prakash Parmar 
wrote:

> Hi,
>
> Schematic wise both are same.
>
> On Wed, Sep 17, 2014 at 2:51 AM, Jesse Cobra  wrote:
>
>> OK, and what is different between your board and CircuitCo schematic wise?
>> On Sep 16, 2014 8:53 AM, "Prakash Parmar" 
>> wrote:
>>
>>> Hi,
>>>
>>> Here CircuitCo cape is not available So we decided to make our own.
>>>
>>>
>>> On Tue, Sep 16, 2014 at 7:20 PM, Jesse Cobra 
>>> wrote:
>>>
 What happens when you try the CircuitCO audio cape?
 Does it work fine?

 On Mon, Sep 15, 2014 at 10:14 PM, Prakash Parmar <
 prakash.parma...@gmail.com> wrote:

> Hi,
>
> How I can check this two things ?
>
> 2) check if SYS_RESET is actually deasserted and high
> 3) check if DIN/DOUT are correctly connected and not flipped, because
> DIN data must go into CODEC, while DOUT must go out and vise versa
>
> I'm not clear about this. Actually I have two Boards one with 10K
> resistors and one with 4.6K .
>
> Thanks & Regards,
> Prakash P.
>
> On Tue, Sep 16, 2014 at 12:34 AM, Maxim Podbereznyy <
> lisar...@gmail.com> wrote:
>
>> what is exactly not clear for you?
>>
>> how to change resistors or how to copy/paste commands in a shell?
>>
>> 2014-09-15 21:46 GMT+04:00 :
>>
>>> HI,
>>> Thanks For reply.
>>>
>>> Can you please tell me how I can Do that ?
>>>
>>>
>>> Thanks & Regards,
>>> Prakash P.
>>>
>>> On Monday, September 15, 2014 8:01:19 PM UTC+5:30, liyaoshi wrote:

 Have you config the i2c pin pulled up ?
 and
 whats the speed of your i2c bus ?

 2014-09-15 2:09 GMT+08:00 :

> Hi,
>
> I have made custom Audio cape using TLV320AIC3107. Here is a
> circuit diagram :
>
>
> 
>
>
> I make it same  ( Pin configurations and all ) as what is
> available at CircuitCO using TLC320AIC3104 codec. I follow All steps 
> like
> Disable HDMI and Load Device Tree BB-BONE-AUDI-02-00A0.dts  and I it 
> works
> fine.
>
> But my problem is when I run speaker-test system hangs (freezes)
> and I have to Hard Reset BeagleBone.
>
> Here is what i did and what I get in dmesg.
>
>
> *root@beaglebone:~# speaker-test *
>
> speaker-test 1.0.25
>
> Playback device is default
> Stream parameters are 48000Hz, S16_LE, 1 channels
> Using 16 octaves of pink noise
> Rate set to 48000Hz (requested 48000Hz)
> Buffer size range from 128 to 32768
> Period size range from 8 to 2048
> Using max buffer size 32768
> Periods = 4
>
>
> *And in Dmesg : *
>
> [  205.540653] omap_i2c 4819c000.i2c: Arbitration lost
> [  206.572921] omap_i2c 4819c000.i2c: controller timed out
> [  206.580024] omap_i2c 4819c000.i2c: Arbitration lost
> [  207.611983] omap_i2c 4819c000.i2c: controller timed out
> [  207.618668] omap_i2c 4819c000.i2c: Arbitration lost
> [  212.626062] omap_i2c 4819c000.i2c: Arbitration lost
> [  213.658853] omap_i2c 4819c000.i2c: controller timed out
> [  213.666881] omap_i2c 4819c000.i2c: Arbitration lost
> [  214.699867] omap_i2c 4819c000.i2c: controller timed out
> [  214.707912] omap_i2c 4819c000.i2c: Arbitration lost
> [  215.740887] omap_i2c 4819c000.i2c: controller timed out
> [  215.748952] omap_i2c 4819c000.i2c: Arbitration lost
>
>
> I also cross check device tree file and I found that it also works
> for TLV320AIC3107 codec So I think it is not issue.
>
> An one have Idea what is wrong Please Help ME 
>
>
> Thanks & Regards
>
> Prakash P.
>
>  --
> 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 beagleboa

Re: [beagleboard] Custom Audio cape with TLV320AIC3107 codec.

[Prakash Parmar]

Hi,

Schematic wise both are same.

On Wed, Sep 17, 2014 at 2:51 AM, Jesse Cobra  wrote:

> OK, and what is different between your board and CircuitCo schematic wise?
> On Sep 16, 2014 8:53 AM, "Prakash Parmar" 
> wrote:
>
>> Hi,
>>
>> Here CircuitCo cape is not available So we decided to make our own.
>>
>>
>> On Tue, Sep 16, 2014 at 7:20 PM, Jesse Cobra 
>> wrote:
>>
>>> What happens when you try the CircuitCO audio cape?
>>> Does it work fine?
>>>
>>> On Mon, Sep 15, 2014 at 10:14 PM, Prakash Parmar <
>>> prakash.parma...@gmail.com> wrote:
>>>
 Hi,

 How I can check this two things ?

 2) check if SYS_RESET is actually deasserted and high
 3) check if DIN/DOUT are correctly connected and not flipped, because
 DIN data must go into CODEC, while DOUT must go out and vise versa

 I'm not clear about this. Actually I have two Boards one with 10K
 resistors and one with 4.6K .

 Thanks & Regards,
 Prakash P.

 On Tue, Sep 16, 2014 at 12:34 AM, Maxim Podbereznyy >>> > wrote:

> what is exactly not clear for you?
>
> how to change resistors or how to copy/paste commands in a shell?
>
> 2014-09-15 21:46 GMT+04:00 :
>
>> HI,
>> Thanks For reply.
>>
>> Can you please tell me how I can Do that ?
>>
>>
>> Thanks & Regards,
>> Prakash P.
>>
>> On Monday, September 15, 2014 8:01:19 PM UTC+5:30, liyaoshi wrote:
>>>
>>> Have you config the i2c pin pulled up ?
>>> and
>>> whats the speed of your i2c bus ?
>>>
>>> 2014-09-15 2:09 GMT+08:00 :
>>>
 Hi,

 I have made custom Audio cape using TLV320AIC3107. Here is a
 circuit diagram :


 


 I make it same  ( Pin configurations and all ) as what is available
 at CircuitCO using TLC320AIC3104 codec. I follow All steps like Disable
 HDMI and Load Device Tree BB-BONE-AUDI-02-00A0.dts  and I it works 
 fine.

 But my problem is when I run speaker-test system hangs (freezes)
 and I have to Hard Reset BeagleBone.

 Here is what i did and what I get in dmesg.


 *root@beaglebone:~# speaker-test *

 speaker-test 1.0.25

 Playback device is default
 Stream parameters are 48000Hz, S16_LE, 1 channels
 Using 16 octaves of pink noise
 Rate set to 48000Hz (requested 48000Hz)
 Buffer size range from 128 to 32768
 Period size range from 8 to 2048
 Using max buffer size 32768
 Periods = 4


 *And in Dmesg : *

 [  205.540653] omap_i2c 4819c000.i2c: Arbitration lost
 [  206.572921] omap_i2c 4819c000.i2c: controller timed out
 [  206.580024] omap_i2c 4819c000.i2c: Arbitration lost
 [  207.611983] omap_i2c 4819c000.i2c: controller timed out
 [  207.618668] omap_i2c 4819c000.i2c: Arbitration lost
 [  212.626062] omap_i2c 4819c000.i2c: Arbitration lost
 [  213.658853] omap_i2c 4819c000.i2c: controller timed out
 [  213.666881] omap_i2c 4819c000.i2c: Arbitration lost
 [  214.699867] omap_i2c 4819c000.i2c: controller timed out
 [  214.707912] omap_i2c 4819c000.i2c: Arbitration lost
 [  215.740887] omap_i2c 4819c000.i2c: controller timed out
 [  215.748952] omap_i2c 4819c000.i2c: Arbitration lost


 I also cross check device tree file and I found that it also works
 for TLV320AIC3107 codec So I think it is not issue.

 An one have Idea what is wrong Please Help ME 


 Thanks & Regards

 Prakash P.

  --
 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.
>>
>
>
>
> --
> LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
> Company - http://www.linkedin.com/company/mentorel
> Facebook - https://www.facebook.com/mentorel.company
>
> --
> For more options, visit h

Re: [beagleboard] Re: RFC: Add mode setting to bone-pinmux-helper

[Charles Steinkuehler]

On 9/16/2014 9:24 PM, Robert Nelson wrote:
> On Tue, Sep 16, 2014 at 9:17 PM, Charles Steinkuehler
>  wrote:
>>
>> Is there any chance working HDMI support can be compiled as a loadable
>> module?  When I was experimenting with trying to get sgx support
>> working, it seemed like there were circular dependencies that prevented
>> this.
> 
> Sure, we can move those to modules:
> 
> I'll set them up exactly like ti has them by default in 3.14. ;)
> 
> CONFIG_BACKLIGHT_PWM=m
> CONFIG_DRM=m
> CONFIG_DRM_KMS_HELPER=m
> CONFIG_DRM_KMS_FB_HELPER=y
> CONFIG_DRM_GEM_CMA_HELPER=y
> CONFIG_DRM_KMS_CMA_HELPER=y
> CONFIG_DRM_I2C_NXP_TDA998X=m
> CONFIG_DRM_TILCDC=m

Great!

That should fix any potential issues with disabling HDMI at runtime
(assuming the module can actually be unloaded).  As for getting the HDMI
display running at power-on, there will likely be a delay (even if
loaded via an initial ramdisk), but I don't think total time to "usable
GUI" should be affected (famous last words!).

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Installing Kali Linux (Arm) onto BeagleBone Black Rev C

[Jason Kridner]

Don't miss "The Deck" either.

On Tue, Sep 16, 2014 at 10:36 PM, Don deJuan  wrote:
> On 09/16/2014 02:19 PM, vermins...@gmail.com wrote:
>
> http://www.offensive-security.com/kali-linux-vmware-arm-image-download/
>
>
>
> On Tuesday, September 16, 2014 12:47:59 PM UTC-7, macuber...@gmail.com
> wrote:
>>
>> Would anyone know of a set of instructions on how to install Kali to the
>> BeagleBone Black Rev C?
>
> --
> 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.
>
>
> They also state it does not have great performance on BBB. Try out
> ArchAssault, way more customizable and lightweight. Its exactly the pwnbox
> you desire the only bloat that is there is what you put on it.
>
> --
> 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] Re: Installing Kali Linux (Arm) onto BeagleBone Black Rev C

[Don deJuan]

On 09/16/2014 02:19 PM, vermins...@gmail.com wrote:
> http://www.offensive-security.com/kali-linux-vmware-arm-image-download/
>
>
>
> On Tuesday, September 16, 2014 12:47:59 PM UTC-7, macuber...@gmail.com
> wrote:
>
> Would anyone know of a set of instructions on how to install Kali
> to the BeagleBone Black Rev C?
>
> -- 
> 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.

They also state it does not have great performance on BBB. Try out
ArchAssault, way more customizable and lightweight. Its exactly the
pwnbox you desire the only bloat that is there is what you put on it.

-- 
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: RFC: Add mode setting to bone-pinmux-helper

[Robert Nelson]

On Tue, Sep 16, 2014 at 9:17 PM, Charles Steinkuehler
 wrote:
> On 9/16/2014 8:53 PM, Robert Nelson wrote:
>>
>> One of the big unknowns i have... How will the "fat"
>> am335x-boneblack.dtb compare with a -.dtb power wise.
>> Switching i2c/spi/usart/gpio worked well with the 3.8 cape-universal.
>> The big one is getting the hdmi/drm stack to seamlessly work with this
>> setup.
>
> Is there any chance working HDMI support can be compiled as a loadable
> module?  When I was experimenting with trying to get sgx support
> working, it seemed like there were circular dependencies that prevented
> this.

Sure, we can move those to modules:

I'll set them up exactly like ti has them by default in 3.14. ;)

CONFIG_BACKLIGHT_PWM=m
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_GEM_CMA_HELPER=y
CONFIG_DRM_KMS_CMA_HELPER=y
CONFIG_DRM_I2C_NXP_TDA998X=m
CONFIG_DRM_TILCDC=m

Regards,

-- 
Robert Nelson
http://www.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] Re: RFC: Add mode setting to bone-pinmux-helper

[Charles Steinkuehler]

On 9/16/2014 8:53 PM, Robert Nelson wrote:
> 
> One of the big unknowns i have... How will the "fat"
> am335x-boneblack.dtb compare with a -.dtb power wise.
> Switching i2c/spi/usart/gpio worked well with the 3.8 cape-universal.
> The big one is getting the hdmi/drm stack to seamlessly work with this
> setup.

Is there any chance working HDMI support can be compiled as a loadable
module?  When I was experimenting with trying to get sgx support
working, it seemed like there were circular dependencies that prevented
this.

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Why did my BB die ?

[Andrew Daviel]

Thanks everyone for the replies.

On Thu, 4 Sep 2014, ja...@acs4design.com wrote:


 1. The voltage sequencing mentioned by Gerald is big and is probably the real 
failure mode.  In this design, the AIN pins will see voltage
long before the CPU/PMIC (Power Management IC) is up and running.  
Basically, when a voltage is applied to the analog pins (or any IO
pins for that matter) before the IO rail is up, the chip tries to power 
itself through the pin clamping diodes and can really cause havoc
on the silicon. The chip just wasn't made to be powered this way.
 2. Did you check that the 1Ohm resistor didn't blow or that the voltage across 
it didn't exceed the limit for the ADC inputs?  If it does
fail open for some reason, the voltage would far exceed the max voltage on 
the Analog pins.  Might want to add some protection there in
case that resistor ever does blow, or the voltage across it exceeds the max 
analog voltage.
 3. Also note that the 1Ohm resistor isn't just powering the BBB, it's charging 
the battery!  Chances are the solar panel was putting too
much juice into the battery and caused the 1Ohm resistor to have a much 
larger voltage across it.
 4. You might move the 1Ohm resistor to the ground leg between the battery and 
the solar panel, instead of between the solar panel and the
battery.


This is a 4W panel, and a fairly hefty 1ohm resistor - 5W or something. It 
can't have blown.

Mmph, I think I've been stupid. The way I originally drew the circuit, it 
looked like AIN1 would be at +200mV, but now I think it would be at 
-200mV. I didn't have any more 150K in my box and thought I could put the 
resistor in the ground leg instead of the +ve leg.


With the ground connection to the battery loose, AIN5 could have been 
overpowered at about 3V, but limited to less than 200uA by the 150K 
resistor, while AIN1 had no current limit.


I'd have expected a problem on an AIN pin to have just blown that input, 
rather than the whole board, though.



Andrew

--
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 vs rootfs dependencies, general guidence, newbie

[Robert Nelson]

On Tue, Sep 16, 2014 at 6:01 PM, pthor  wrote:
> Hi guys,
>
> I'm just about to start up my second try at learning more embedded linux,
> and got myself a BBB. I'm somewhat unexperienced with embedded linux, but
> have done some stuff (and reading) earlier: building kernels, applied some
> patches, building Qt, tslib, gstreamer for angstrom. But I have some doubts
> now and hope that you may help me with some guidence with a few specific and
> some more general questions.
>
> My longterm goals is to set up a system where I can run newest Qt, support
> for display, audio and be able to play with driver and application
> development.
>
> Where I am:
> - I've done some research lately and it seems like I want a newer kernel
> (3.14 for example) with SGX fixes, (for Qt 5)
> - The only graphical application I want to run is my own custom one, so I
> feel that "non GUI" Angstrom distro fits better than the supplied Debian
> distro. But I'm a little clueless regarding the roofs.
> - Earlier I have relied on the distro provided with a development board, now
> I want better control and understanding.
>
> Is there any dependencies between the beaglebone 3.14 kernel and rootfs?
> Is it supposed to run with Debian rootfs only?

Really any current "rootfs" that can at-least run 2.6.32, will boot
fine with this 3.14.  The kernel config already includes all the
dependices for systemd by default. (I do need to re-add the Android
configs).  So, really, it should just work, if it doesn't just ping
this list and we will get that missing config enabled.

> Can use the Angstrom build tool(or other method) to build a Angstrom rootfs
> and use the beaglebone 3.14 kernel "out of the box"?
> Is there any version dependencies in the rootfs that I need to worry about?
> Is there any benefit to look into yocto for me? It seems a bit overwhelming
> for me, at least now.
>
> (With beaglebone 3.14 kernel i mean the kernel discussed in: BeagleBone
> Black switching to 3.14 kernel )
>
> I dont understand all the details yet, but is all the beaglebone specific
> driver/cape/dts stuff provided with the kernel? Or is there some BSP stuff I
> need to provide in the rootfs? BSP is per definition a part of the kernel?

Any tool not found in a current distro, can be found at:

https://github.com/beagleboard/

> I have some books on device drivers and embedded linux from 2.6 kernel era.
> Is these books still relevant with 3.x kernels? Do you have some keywords
> regarding important topics that have changed? I guess Device tree is one.

Device Tree should be in the books from 2.6 kernel, back then it was
mostly a powerpc thing. It wasn't till late in the 2.6.xx/ early 3.x
series did device tree's become "bootable" and till 3.10.x when it
became "very*" useful. (* multarch became useful, imx+omap same
kernel)

Regards,

-- 
Robert Nelson
http://www.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] Re: RFC: Add mode setting to bone-pinmux-helper

[Robert Nelson]

On Tue, Sep 16, 2014 at 4:55 PM, Joshua Datko  wrote:
>
>
> Jason Kridner  writes:
>
>
>>> https://github.com/cdsteinkuehler/beaglebone-universal-io/commit/e742ff15f7abbc2cf80141ea49269eb0a2f2a8b3
>>
>> Approach looks good to me. I know the dropping of the pin assignment
>> in the i2c device tree itself will cause some heartache for some.
>>
>> I don't see where you removed the definition of the i2c pin settings
>> themselves. Will not removing those entries cause headaches by someone
>> assuming they are used or is it comfortable for them to simply be
>> there by reference? I suspect it would only be an issue if a bug was
>> found in the setting and someone missed that the real mode was coming
>> from the helper.
>>
>
> I've been trying to follow along with these changes and I admit, I
> haven't been able to keep up.
>
> Some questions:
>
> 1. My Cape DTS does not explicitly call out for i2c2 [1], with this
> change does that, and all capes using i2c2, need to be fixed?
>
> 2. Is the default mode of pins P_19/20, once user space is reached, GPIO
> or i2c2?

Hi Josh,

I'm going to make sure we do it both ways. The default
"am335x-boneblack.dtb" () will have every peripheral
enabled and it'll be up to Charles's userspace tool (and a cape
database file that we need to write, (it'll probably be bone-script))
to correctly setup the pinmux's for your cape.

But i'll also have a backup: -.dtb, that'll just be the
minimal needed for your cape. Which the end user could enable "other"
stuff just like in this base dts:

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-crypto-00a0.dts

One of the big unknowns i have... How will the "fat"
am335x-boneblack.dtb compare with a -.dtb power wise.
Switching i2c/spi/usart/gpio worked well with the 3.8 cape-universal.
The big one is getting the hdmi/drm stack to seamlessly work with this
setup.

Regards,

-- 
Robert Nelson
http://www.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] RFC: Add mode setting to bone-pinmux-helper

[Robert Nelson]

On Tue, Sep 16, 2014 at 3:53 PM, Charles Steinkuehler
 wrote:
> Request For Comment
> ===
>
> In order to make the cape-universal approach to modifying the BeagleBone
> I/O setup at runtime via user-land (ie: no kernel driver and no
> device-tree overlays or changesets), the bone-pinmux-helper driver needs
> to be in control of the pinmux register for each I/O pin.  It is not
> currently possible, however, to (easily) set the default pinmux mode for
> the bone-pinmux-helper.
>
> Therefore, I have modified the bone-pinmux-helper code to support a
> "mode" parameter in the device tree:
>
> https://github.com/cdsteinkuehler/linux/commit/e0e0f1da3f2df4bc4ee2b27a65ee99734bd3fb77
>
> ...which allows a device tree fragment to specify the startup default
> mode of the pinmux from one of the available choices:

Nice work, i like this!  I'll cherry-pick it tomorrow and also start
the conversion ttOx/i2c/spi..

Regards,

-- 
Robert Nelson
http://www.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] PyBBIO v0.9.2 update

[Alexander Hiam]

(http://www.alexanderhiam.com/blog/pybbio-update-version-0-9-2/)

A few new features have been added in version 0.9.2:
WebCam library 

The last of the GSoC 2014 additions from rseetham 
, the WebCam library allows live streaming of 
WebCam video over TCP, as well as capturing of still images to JPG files.
BBIOServer updates 

The included JQuery has been updated to version 1.11.1. Also merged an 
update from Ikario  that adds a range slider 
input element.
I2C improvement 

ycoroneos  added new *quickwrite()* and 
*readTransaction()* methods to the I2C objects that allow communicating 
with a wider range of devices.

To update to v0.9.2:
 # pip install --upgrade PyBBIO

-- 
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: RFC: Add mode setting to bone-pinmux-helper

[Jason Kridner]

On Tue, Sep 16, 2014 at 7:09 PM, Charles Steinkuehler
 wrote:
> On 9/16/2014 5:37 PM, Jason Kridner wrote:
>>
>> Just going along to state the obvious...
>>
>> eMMC and HDMI will be equally interesting tests and more practically
>> useful for more capes.
>
> I'll try and work up a patch set for HDMI, but it won't be until tomorrow.
>
>> It will only be a matter of time before someone damages a board by:
>> A) setting an HDMI pin to a output without disabling the HDMI
>
> The worst that can happen with HDMI is a bus fight (driving an HDMI pin
> without first configuring the BBB side as an input).  The HDMI framer
> does not drive any signals back to the AM335x (other than I2C), so it
> won't cause problems.  If you start playing with pinmux values you could
> easily see wonky video, but that's not a "break the hardware" kind of
> problem.

Yeah, brainfart.  Agreed, no potential damaging hardware issues.
Anything like an LCD add-on board would just have inputs on those
signals as well.

>
>> B) driving an eMMC pin into conflict without putting the eMMC in reset
>
> This is much more likely, and while it might not be easy to destroy the
> hardware, it is probably pretty easy to corrupt the eMMC.  It might be
> worth requiring loading an alternate device-tree to disable the eMMC,
> which can make sure it stays in reset.

Getting all of those HDMI pins back for GPIO when not using HDMI w/o
needing to do anything special on boot should make a lot of people
happy, even if the eMMC pins aren't available.

>
>> I don't think there is a simple way for the current pinmux helper to
>> check for these conditions, but it wouldn't hurt if any config-pin
>> sort of utility would check the state of those hardware control bits
>> before helping someone screw things up. :-)
>
> Agreed!
>
>> Any way you can imagine a way to keep the current uEnv.txt lines to
>> disable both of those working without breaking compatibility?
>
> Maybe, there's some groundwork to do first.  For instance I still don't
> know what happens if you leave the HDMI enabled, but take all the pins
> out from under it via the pinmux.  I'll keep this in mind and see what I
> can come up with...
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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: Angstrom USB networking Verizon Modem

[edwin . j . slv]

What specific information are you looking for from "lsusb -vvv"? I posted 
it below.  I am still not able to see the network option "ppp0" or "eth1". 
 I have tried Anstrom Distribution 3.8.13 and Ubuntu 14.04. 




lsusb -vvv

Bus 001 Device 002: ID 1410:b001 Novatel Wireless Ovation MC551
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x1410 Novatel Wireless
  idProduct  0xb001 Ovation MC551
  bcdDevice0.15
  iManufacturer   4
  iProduct3
  iSerial 5
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  231
bNumInterfaces  6
bConfigurationValue 1
iConfiguration  2
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescript

Re: [beagleboard] Re: Adafruit serial UART library seems to have wrong tty names

[Mike]

On 09/16/2014 06:40 AM, c...@isbd.net wrote:

Michel Lavoie  wrote:

[-- text/plain, encoding quoted-printable, charset: UTF-8, 81 lines --]

I strongly recommend that you read Adafruit's guide regarding the BBB's
device tree overlay. It really help me put this all together:
https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview

You will find there why and how to modify your uEnv.txt file in order to
enable ttyO1. In mine, the last line looks like this:

...
optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0

optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0

optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0

optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0



The Adafruit UART IO documentation specifically says that it *does*
export the overlays:-

 The Adafruit IO Python library will export the UART device tree
 overlays as a convenience. There are five serial ports brought to
 the expansion headers (UART3 only has a single direction, TX), and
 one (UART0) with dedicated headers that aren't available to use in
 your Python programs.

... but not all the UARTs work.

In addition the use of the letter O in the device name is just silly! :-)

The devices it creates are called /dev/ttyO1, /dev/ttyO2, etc. with
the letter O.  There's not a mention anywhere that it's a letter
rather than a digit and given the context it's second nature to assume
it's a zero.  Still I did spot that eventually.

Yes, the O and not zero threw me for a loop when I was first setting up 
serial on the BBB.  I have no clue where/why that choice was made.


I haven't looked into the Adafruit library, my hunch here is that to use 
uart5 you will have to disable HDMI as the pins used for that uart are 
in the HDMI group.  As noted above uart3 is TX only, and again those 
pins fall within the HDMI group.


For what it's worth I referenced that info from here.

https://github.com/derekmolloy/boneDeviceTree/blob/master/docs/BeagleboneBlackP8HeaderTable.pdf
https://github.com/derekmolloy/boneDeviceTree/blob/master/docs/BeagleboneBlackP9HeaderTable.pdf

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.

[beagleboard] uio_pruss in Ubuntu 12.04.

[Alan Federman]

How do I insert uio_pruss for ubuntu 12.04?   I am not sure were to get 
this module or if it exists for my kernel.

uname -a
Linux ubuntu-armhf 3.14.4.1-bone-armhf.com #1 SMP Tue Jun 3 12:37:22 UTC 
2014 armv7l armv7l armv7l GNU/Linux


Only "pru" mention in dtbs am335x-boneblack.dtb

 pruss_ocp_gclk {
#clock-cells = <0x0>;
compatible = "ti,mux-clock";
clocks = <0x10 0x11>;
reg = <0x530>;
};

-- 
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: RFC: Add mode setting to bone-pinmux-helper

[Sungjin Chun]

Thank you. I've just changed state of hdmi in
/boot/dtbs/am335x-boneblack.dtb as disabled, however,
which might not be a correct way of disabling HDMI, so I asked.

On Wed, Sep 17, 2014 at 7:57 AM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 9/16/2014 5:43 PM, Sungjin Chun wrote:
> > Maybe somewhat off topic, however I cannot help but to ask this;
> >
> > "How can we disable HDMI in kernel version >= 3.14?" where we do not
> > have capemgr?
>
> Load a different device tree.  There's probably an easier way (there are
> several available device trees already installed), but I would:
>
> cd /opt/source/dtb-3.14-ti
> vi src/arm/am335x-boneblack.dts
>
> 
>
> make
> sudo make install
> sudo reboot
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: RFC: Add mode setting to bone-pinmux-helper

[Charles Steinkuehler]

On 9/16/2014 5:37 PM, Jason Kridner wrote:
> 
> Just going along to state the obvious...
> 
> eMMC and HDMI will be equally interesting tests and more practically
> useful for more capes.

I'll try and work up a patch set for HDMI, but it won't be until tomorrow.

> It will only be a matter of time before someone damages a board by:
> A) setting an HDMI pin to a output without disabling the HDMI

The worst that can happen with HDMI is a bus fight (driving an HDMI pin
without first configuring the BBB side as an input).  The HDMI framer
does not drive any signals back to the AM335x (other than I2C), so it
won't cause problems.  If you start playing with pinmux values you could
easily see wonky video, but that's not a "break the hardware" kind of
problem.

> B) driving an eMMC pin into conflict without putting the eMMC in reset

This is much more likely, and while it might not be easy to destroy the
hardware, it is probably pretty easy to corrupt the eMMC.  It might be
worth requiring loading an alternate device-tree to disable the eMMC,
which can make sure it stays in reset.

> I don't think there is a simple way for the current pinmux helper to
> check for these conditions, but it wouldn't hurt if any config-pin
> sort of utility would check the state of those hardware control bits
> before helping someone screw things up. :-)

Agreed!

> Any way you can imagine a way to keep the current uEnv.txt lines to
> disable both of those working without breaking compatibility?

Maybe, there's some groundwork to do first.  For instance I still don't
know what happens if you leave the HDMI enabled, but take all the pins
out from under it via the pinmux.  I'll keep this in mind and see what I
can come up with...

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Kernel vs rootfs dependencies, general guidence, newbie

[pthor]

Hi guys,

I'm just about to start up my second try at learning more embedded linux, 
and got myself a BBB. I'm somewhat unexperienced with embedded linux, but 
have done some stuff (and reading) earlier: building kernels, applied some 
patches, building Qt, tslib, gstreamer for angstrom. But I have some doubts 
now and hope that you may help me with some guidence with a few specific 
and some more general questions.

My longterm goals is to set up a system where I can run newest Qt, support 
for display, audio and be able to play with driver and application 
development. 

Where I am:
- I've done some research lately and it seems like I want a newer kernel 
(3.14 for example) with SGX fixes, (for Qt 5) 
- The only graphical application I want to run is my own custom one, so I 
feel that "non GUI" Angstrom distro fits better than the supplied Debian 
distro. But I'm a little clueless regarding the roofs.
- Earlier I have relied on the distro provided with a development board, 
now I want better control and understanding.

*Is there any dependencies between the beaglebone 3.14 kernel and rootfs?*
Is it supposed to run with Debian rootfs only?
Can use the Angstrom build tool 
(or other method) to build a 
Angstrom rootfs and use the beaglebone 3.14 kernel "out of the box"?
Is there any version dependencies in the rootfs that I need to worry about?
Is there any benefit to look into yocto for me? It seems a bit overwhelming 
for me, at least now.

(With beaglebone 3.14 kernel i mean the kernel discussed in: BeagleBone 
Black switching to 3.14 kernel 

 )

*I dont understand all the details yet, but is all the beaglebone specific 
driver/cape/dts stuff provided with the kernel? Or is there some BSP stuff 
I need to provide in the rootfs? BSP is per definition a part of the 
kernel?*

*I have some books on device drivers and embedded linux from 2.6 kernel 
era. Is these books still relevant with 3.x kernels? Do you have some 
keywords regarding important topics that have changed? I guess Device tree 
is one.*

Sorry for a little long and unfocused thread, but I need some direction 
before I can contribiute more specific.
Any help is very much appreciated!

-- 
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: RFC: Add mode setting to bone-pinmux-helper

[Charles Steinkuehler]

On 9/16/2014 5:43 PM, Sungjin Chun wrote:
> Maybe somewhat off topic, however I cannot help but to ask this;
> 
> "How can we disable HDMI in kernel version >= 3.14?" where we do not
> have capemgr?

Load a different device tree.  There's probably an easier way (there are
several available device trees already installed), but I would:

cd /opt/source/dtb-3.14-ti
vi src/arm/am335x-boneblack.dts



make
sudo make install
sudo reboot

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RFC: Add mode setting to bone-pinmux-helper

[Sungjin Chun]

Maybe somewhat off topic, however I cannot help but to ask this;

"How can we disable HDMI in kernel version >= 3.14?" where we do not
have capemgr?

On Wed, Sep 17, 2014 at 7:37 AM, Jason Kridner 
wrote:

> On Tue, Sep 16, 2014 at 6:06 PM, Charles Steinkuehler
>  wrote:
> > On 9/16/2014 4:55 PM, Joshua Datko wrote:
> >>
> >> I've been trying to follow along with these changes and I admit, I
> >> haven't been able to keep up.
> >>
> >> Some questions:
> >>
> >> 1. My Cape DTS does not explicitly call out for i2c2 [1], with this
> >> change does that, and all capes using i2c2, need to be fixed?
> >
> > The i2c2 is typically defined by the base BeagleBone device tree (or
> > more specifically, am335x-bone-common-pinmux.dtsi in Robert's latest
> > device trees for 3.14).  The cape dtsi files (or overly files for 3.8)
> > generally only include things that need to be changed to support the
> > cape, so unless you were intentionally trying to modify the i2c2
> > hardware, you wouldn't reference it in you cape file.
> >
> > Your cape file simply adds some target entries for the i2c2 bus, which
> > would work as expected and need no changes regardless of whether the
> > i2c2 pinmux is handled directly or by using the bone-pinmux-helper (the
> > device tree compiler will merge the main i2c2 definitions with your
> > additions).  By way of similar example, you're also not specifying the
> > base address of the i2c2 hardware, the interrupt(s) it uses, etc, but
> > that all works since it's pulled in from common dts files before your
> > cape file is included.
> >
> >> 2. Is the default mode of pins P_19/20, once user space is reached, GPIO
> >> or i2c2?
> >
> > The purpose of this change is to allow the pinmux-helper to be in
> > control of the pin, but have it come up in the desired mode (i2c in this
> > case) instead of the default gpio mode, which is what would have
> > happened previously.
>
> Just going along to state the obvious...
>
> eMMC and HDMI will be equally interesting tests and more practically
> useful for more capes.
>
> It will only be a matter of time before someone damages a board by:
> A) setting an HDMI pin to a output without disabling the HDMI
> B) driving an eMMC pin into conflict without putting the eMMC in reset
>
> I don't think there is a simple way for the current pinmux helper to
> check for these conditions, but it wouldn't hurt if any config-pin
> sort of utility would check the state of those hardware control bits
> before helping someone screw things up. :-)
>
> Any way you can imagine a way to keep the current uEnv.txt lines to
> disable both of those working without breaking compatibility?
>
> >
> > --
> > Charles Steinkuehler
> > char...@steinkuehler.net
> >
> > --
> > For more options, visit http://beagleboard.org/discuss
> > ---
> > You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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] Re: RFC: Add mode setting to bone-pinmux-helper

[Jason Kridner]

On Tue, Sep 16, 2014 at 6:06 PM, Charles Steinkuehler
 wrote:
> On 9/16/2014 4:55 PM, Joshua Datko wrote:
>>
>> I've been trying to follow along with these changes and I admit, I
>> haven't been able to keep up.
>>
>> Some questions:
>>
>> 1. My Cape DTS does not explicitly call out for i2c2 [1], with this
>> change does that, and all capes using i2c2, need to be fixed?
>
> The i2c2 is typically defined by the base BeagleBone device tree (or
> more specifically, am335x-bone-common-pinmux.dtsi in Robert's latest
> device trees for 3.14).  The cape dtsi files (or overly files for 3.8)
> generally only include things that need to be changed to support the
> cape, so unless you were intentionally trying to modify the i2c2
> hardware, you wouldn't reference it in you cape file.
>
> Your cape file simply adds some target entries for the i2c2 bus, which
> would work as expected and need no changes regardless of whether the
> i2c2 pinmux is handled directly or by using the bone-pinmux-helper (the
> device tree compiler will merge the main i2c2 definitions with your
> additions).  By way of similar example, you're also not specifying the
> base address of the i2c2 hardware, the interrupt(s) it uses, etc, but
> that all works since it's pulled in from common dts files before your
> cape file is included.
>
>> 2. Is the default mode of pins P_19/20, once user space is reached, GPIO
>> or i2c2?
>
> The purpose of this change is to allow the pinmux-helper to be in
> control of the pin, but have it come up in the desired mode (i2c in this
> case) instead of the default gpio mode, which is what would have
> happened previously.

Just going along to state the obvious...

eMMC and HDMI will be equally interesting tests and more practically
useful for more capes.

It will only be a matter of time before someone damages a board by:
A) setting an HDMI pin to a output without disabling the HDMI
B) driving an eMMC pin into conflict without putting the eMMC in reset

I don't think there is a simple way for the current pinmux helper to
check for these conditions, but it wouldn't hurt if any config-pin
sort of utility would check the state of those hardware control bits
before helping someone screw things up. :-)

Any way you can imagine a way to keep the current uEnv.txt lines to
disable both of those working without breaking compatibility?

>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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] Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev- instead.

[Florian Hänel]

I am getting these messages multiple times per second:

any idea whats going on here? how do I find out which device is causing it?

Sep 16 23:32:18 rgbmatrix cron[779]: (CRON) STARTUP (fork ok)
Sep 16 23:32:18 rgbmatrix cron[779]: (CRON) INFO (Running @reboot jobs)
Sep 16 23:32:20 rgbmatrix udhcpd[992]: udhcpd (v1.21.1) started
Sep 16 23:32:20 rgbmatrix udhcpd[992]: is interface usb0 up and configured?: 
Cannot assign requested address
Sep 16 23:32:20 rgbmatrix udhcpd[1022]: udhcpd (v1.21.1) started
Sep 16 23:32:20 rgbmatrix udhcpd[1022]: is interface usb0 up and configured?: 
Cannot assign requested address
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Joining mDNS multicast group on 
interface usb0.IPv4 with address 192.168.7.2.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: New relevant interface usb0.IPv4 
for mDNS.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Registering new address record for 
192.168.7.2 on usb0.IPv4.
Sep 16 23:32:20 rgbmatrix kernel: [   22.074688] IPv6: ADDRCONF(NETDEV_UP): 
usb0: link is not ready
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Withdrawing address record for 
192.168.7.2 on usb0.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Leaving mDNS multicast group on 
interface usb0.IPv4 with address 192.168.7.2.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Interface usb0.IPv4 no longer 
relevant for mDNS.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Joining mDNS multicast group on 
interface usb0.IPv4 with address 192.168.7.2.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: New relevant interface usb0.IPv4 
for mDNS.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Registering new address record for 
192.168.7.2 on usb0.IPv4.
Sep 16 23:32:20 rgbmatrix udhcpd[1031]: udhcpd (v1.21.1) started
Sep 16 23:32:25 rgbmatrix kernel: [   26.447805] init: plymouth-upstart-bridge 
main process ended, respawning
Sep 16 23:32:26 rgbmatrix kernel: [   27.339187] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.408049] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.515752] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.631790] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix ntpdate[978]: adjust time server 91.189.89.199 offset 
0.203703 sec
Sep 16 23:32:26 rgbmatrix kernel: [   27.757020] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.849898] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.904060] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.955998] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   28.008765] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   28.064496] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   28.123799] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   28.181981] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   28.239791] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:27 rgbmatrix kernel: [   28.297772] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.


-- 
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: RFC: Add mode setting to bone-pinmux-helper

[Charles Steinkuehler]

On 9/16/2014 4:55 PM, Joshua Datko wrote:
> 
> I've been trying to follow along with these changes and I admit, I
> haven't been able to keep up.
> 
> Some questions:
> 
> 1. My Cape DTS does not explicitly call out for i2c2 [1], with this
> change does that, and all capes using i2c2, need to be fixed?

The i2c2 is typically defined by the base BeagleBone device tree (or
more specifically, am335x-bone-common-pinmux.dtsi in Robert's latest
device trees for 3.14).  The cape dtsi files (or overly files for 3.8)
generally only include things that need to be changed to support the
cape, so unless you were intentionally trying to modify the i2c2
hardware, you wouldn't reference it in you cape file.

Your cape file simply adds some target entries for the i2c2 bus, which
would work as expected and need no changes regardless of whether the
i2c2 pinmux is handled directly or by using the bone-pinmux-helper (the
device tree compiler will merge the main i2c2 definitions with your
additions).  By way of similar example, you're also not specifying the
base address of the i2c2 hardware, the interrupt(s) it uses, etc, but
that all works since it's pulled in from common dts files before your
cape file is included.

> 2. Is the default mode of pins P_19/20, once user space is reached, GPIO
> or i2c2?

The purpose of this change is to allow the pinmux-helper to be in
control of the pin, but have it come up in the desired mode (i2c in this
case) instead of the default gpio mode, which is what would have
happened previously.

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] RFC: Add mode setting to bone-pinmux-helper

[Charles Steinkuehler]

On 9/16/2014 4:42 PM, Jason Kridner wrote:
> 
> Approach looks good to me. I know the dropping of the pin assignment
> in the i2c device tree itself will cause some heartache for some.

Yes, but there's no other way to do this, AFAIK.  I would suggest
migrating the mode= settings and the device stanza into it's own include
file.  I tried more to make the minimal possible changes vs.
restructuring the whole device-tree layout (ie: I didn't want to try and
factor out the i2c2 device into it's own dtsi file).

> I don't see where you removed the definition of the i2c pin settings
> themselves. Will not removing those entries cause headaches by someone
> assuming they are used or is it comfortable for them to simply be
> there by reference? I suspect it would only be an issue if a bug was
> found in the setting and someone missed that the real mode was coming
> from the helper.

I didn't remove them, and they might still be useful.  It possible to
switch between the "old style" of pinmux control for devices and the
pinmux helper version, possibly even by using different dtsi include
files.  At this point I am not trying to advocate any particular device
tree layout (in terms of what goes into which include files), I'm simply
making the feature available.

If the modified pinmux helper is a sensible approach, we can start
talking about exactly what the device tree files should look like.

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: RFC: Add mode setting to bone-pinmux-helper

[Joshua Datko]

Jason Kridner  writes:


>> https://github.com/cdsteinkuehler/beaglebone-universal-io/commit/e742ff15f7abbc2cf80141ea49269eb0a2f2a8b3
>
> Approach looks good to me. I know the dropping of the pin assignment
> in the i2c device tree itself will cause some heartache for some.
>
> I don't see where you removed the definition of the i2c pin settings
> themselves. Will not removing those entries cause headaches by someone
> assuming they are used or is it comfortable for them to simply be
> there by reference? I suspect it would only be an issue if a bug was
> found in the setting and someone missed that the real mode was coming
> from the helper.
>

I've been trying to follow along with these changes and I admit, I
haven't been able to keep up.

Some questions:

1. My Cape DTS does not explicitly call out for i2c2 [1], with this
change does that, and all capes using i2c2, need to be fixed?

2. Is the default mode of pins P_19/20, once user space is reached, GPIO
or i2c2?

Josh


[1] 
https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/29723a20cdfe75e81e964739284643ab32a38231/arch/arm/boot/dts/am335x-bone-crypto-00a0.dtsi

-- 
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] RFC: Add mode setting to bone-pinmux-helper

[Jason Kridner]

On Tue, Sep 16, 2014 at 4:53 PM, Charles Steinkuehler
 wrote:
> Request For Comment
> ===
>
> In order to make the cape-universal approach to modifying the BeagleBone
> I/O setup at runtime via user-land (ie: no kernel driver and no
> device-tree overlays or changesets), the bone-pinmux-helper driver needs
> to be in control of the pinmux register for each I/O pin.  It is not
> currently possible, however, to (easily) set the default pinmux mode for
> the bone-pinmux-helper.
>
> Therefore, I have modified the bone-pinmux-helper code to support a
> "mode" parameter in the device tree:
>
> https://github.com/cdsteinkuehler/linux/commit/e0e0f1da3f2df4bc4ee2b27a65ee99734bd3fb77

I did a quick read through that made sense, though I don't know the
specific functions.

>
> ...which allows a device tree fragment to specify the startup default
> mode of the pinmux from one of the available choices:
>
> https://github.com/cdsteinkuehler/dtb-rebuilder/commit/b78226fdf0c420dcadf8a606e4795cefbc8c7428
>
> ...and a tweaked the config-pin utility supporting the new options:
>
> https://github.com/cdsteinkuehler/beaglebone-universal-io/commit/e742ff15f7abbc2cf80141ea49269eb0a2f2a8b3

Approach looks good to me. I know the dropping of the pin assignment
in the i2c device tree itself will cause some heartache for some.

I don't see where you removed the definition of the i2c pin settings
themselves. Will not removing those entries cause headaches by someone
assuming they are used or is it comfortable for them to simply be
there by reference? I suspect it would only be an issue if a bug was
found in the setting and someone missed that the real mode was coming
from the helper.

>
> This will allow any initial hardware pinmux configuration to be
> overridden by user-space code at run-time, making it possible to switch
> (for instance) the i2c2 cape EEPROM bus to standard GPIO pins as shown
> in this example.

Woohoo! Hold on to your hats!

>
> "Takeover" of the i2c2 bus is intended mainly as a proof-of-concept, the
> real power of this approach is the ability to do things like enable SPI
> or a UART in the boot-time device tree and have the pin muxing correct,
> but be able to override the pinmux settings once the system is booted
> (perhaps turning an unused RxD line into a useful PWM or similar).  This
> also makes it possible to modify the pinmux hardware configuration as
> soon as sysfs is available (ie: very early in the system boot stage).
> Who wants to write the user-mode version of cape-manager?!?

It seems to me that the existing kernel module should be extended.
Extending config-pin to read cape EEPROMs and have a database of pin
settings is fine and I can understanding you wanting to find an owner
for that task, but if looking for a real replacement of cape-manager
(by that name) then real overlays still need to be
understood/supported as you still can't quite do all the
experimenting/fpga-ing you'd desire without being able to reconfigure
the rest of the device tree at runtime.

>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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] Custom Audio cape with TLV320AIC3107 codec.

[Jesse Cobra]

OK, and what is different between your board and CircuitCo schematic wise?
On Sep 16, 2014 8:53 AM, "Prakash Parmar" 
wrote:

> Hi,
>
> Here CircuitCo cape is not available So we decided to make our own.
>
>
> On Tue, Sep 16, 2014 at 7:20 PM, Jesse Cobra  wrote:
>
>> What happens when you try the CircuitCO audio cape?
>> Does it work fine?
>>
>> On Mon, Sep 15, 2014 at 10:14 PM, Prakash Parmar <
>> prakash.parma...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> How I can check this two things ?
>>>
>>> 2) check if SYS_RESET is actually deasserted and high
>>> 3) check if DIN/DOUT are correctly connected and not flipped, because
>>> DIN data must go into CODEC, while DOUT must go out and vise versa
>>>
>>> I'm not clear about this. Actually I have two Boards one with 10K
>>> resistors and one with 4.6K .
>>>
>>> Thanks & Regards,
>>> Prakash P.
>>>
>>> On Tue, Sep 16, 2014 at 12:34 AM, Maxim Podbereznyy 
>>> wrote:
>>>
 what is exactly not clear for you?

 how to change resistors or how to copy/paste commands in a shell?

 2014-09-15 21:46 GMT+04:00 :

> HI,
> Thanks For reply.
>
> Can you please tell me how I can Do that ?
>
>
> Thanks & Regards,
> Prakash P.
>
> On Monday, September 15, 2014 8:01:19 PM UTC+5:30, liyaoshi wrote:
>>
>> Have you config the i2c pin pulled up ?
>> and
>> whats the speed of your i2c bus ?
>>
>> 2014-09-15 2:09 GMT+08:00 :
>>
>>> Hi,
>>>
>>> I have made custom Audio cape using TLV320AIC3107. Here is a circuit
>>> diagram :
>>>
>>>
>>> 
>>>
>>>
>>> I make it same  ( Pin configurations and all ) as what is available
>>> at CircuitCO using TLC320AIC3104 codec. I follow All steps like Disable
>>> HDMI and Load Device Tree BB-BONE-AUDI-02-00A0.dts  and I it works fine.
>>>
>>> But my problem is when I run speaker-test system hangs (freezes) and
>>> I have to Hard Reset BeagleBone.
>>>
>>> Here is what i did and what I get in dmesg.
>>>
>>>
>>> *root@beaglebone:~# speaker-test *
>>>
>>> speaker-test 1.0.25
>>>
>>> Playback device is default
>>> Stream parameters are 48000Hz, S16_LE, 1 channels
>>> Using 16 octaves of pink noise
>>> Rate set to 48000Hz (requested 48000Hz)
>>> Buffer size range from 128 to 32768
>>> Period size range from 8 to 2048
>>> Using max buffer size 32768
>>> Periods = 4
>>>
>>>
>>> *And in Dmesg : *
>>>
>>> [  205.540653] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  206.572921] omap_i2c 4819c000.i2c: controller timed out
>>> [  206.580024] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  207.611983] omap_i2c 4819c000.i2c: controller timed out
>>> [  207.618668] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  212.626062] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  213.658853] omap_i2c 4819c000.i2c: controller timed out
>>> [  213.666881] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  214.699867] omap_i2c 4819c000.i2c: controller timed out
>>> [  214.707912] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  215.740887] omap_i2c 4819c000.i2c: controller timed out
>>> [  215.748952] omap_i2c 4819c000.i2c: Arbitration lost
>>>
>>>
>>> I also cross check device tree file and I found that it also works
>>> for TLV320AIC3107 codec So I think it is not issue.
>>>
>>> An one have Idea what is wrong Please Help ME 
>>>
>>>
>>> Thanks & Regards
>>>
>>> Prakash P.
>>>
>>>  --
>>> 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.
>



 --
 LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
 Company - http://www.linkedin.com/company/mentorel
 Facebook - https://www.facebook.com/mentorel.company

 --
 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/0i

[beagleboard] Re: Installing Kali Linux (Arm) onto BeagleBone Black Rev C

[verminsky2]

http://www.offensive-security.com/kali-linux-vmware-arm-image-download/



On Tuesday, September 16, 2014 12:47:59 PM UTC-7, macuber...@gmail.com 
wrote:
>
> Would anyone know of a set of instructions on how to install Kali to the 
> BeagleBone Black Rev C?
>

-- 
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] RFC: Add mode setting to bone-pinmux-helper

[Charles Steinkuehler]

Request For Comment
===

In order to make the cape-universal approach to modifying the BeagleBone
I/O setup at runtime via user-land (ie: no kernel driver and no
device-tree overlays or changesets), the bone-pinmux-helper driver needs
to be in control of the pinmux register for each I/O pin.  It is not
currently possible, however, to (easily) set the default pinmux mode for
the bone-pinmux-helper.

Therefore, I have modified the bone-pinmux-helper code to support a
"mode" parameter in the device tree:

https://github.com/cdsteinkuehler/linux/commit/e0e0f1da3f2df4bc4ee2b27a65ee99734bd3fb77

...which allows a device tree fragment to specify the startup default
mode of the pinmux from one of the available choices:

https://github.com/cdsteinkuehler/dtb-rebuilder/commit/b78226fdf0c420dcadf8a606e4795cefbc8c7428

...and a tweaked the config-pin utility supporting the new options:

https://github.com/cdsteinkuehler/beaglebone-universal-io/commit/e742ff15f7abbc2cf80141ea49269eb0a2f2a8b3

This will allow any initial hardware pinmux configuration to be
overridden by user-space code at run-time, making it possible to switch
(for instance) the i2c2 cape EEPROM bus to standard GPIO pins as shown
in this example.

"Takeover" of the i2c2 bus is intended mainly as a proof-of-concept, the
real power of this approach is the ability to do things like enable SPI
or a UART in the boot-time device tree and have the pin muxing correct,
but be able to override the pinmux settings once the system is booted
(perhaps turning an unused RxD line into a useful PWM or similar).  This
also makes it possible to modify the pinmux hardware configuration as
soon as sysfs is available (ie: very early in the system boot stage).
Who wants to write the user-mode version of cape-manager?!?

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: CAN bus recovery

[Adrian Remonda]

Witch kernel are you using?  Using the can cape that uses the can1
interface, I'm having some troubles with the 3.8 of Robert.

After I send some packages it just silently stop sending and I have to do a
ifdown ifup in order to make it run again. This didn't  happen with the
Kernel version of the Angstrom.
Any ideas?

Any hint how to activate the can1 in the device tree of the 3.15?


On 12 September 2014 02:21, Brent Sink  wrote:

> Ah, yes.  The TT3201 cape has three CAN channels, but two of them are over
> SPI.  This should help you out...
>
>
> https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/TT3201-001-01.dts
>
>
> On Thu, Sep 11, 2014 at 8:00 PM, William Hermans 
> wrote:
>
>> Thank Brent, However I was more curious about the bring up of the
>> hardware on the BBB. IS there cape file I have not noticed yet ?
>>  If so I can probably figure it out on my own.
>>
>> On Thu, Sep 11, 2014 at 4:52 PM, Brent  wrote:
>>
>>> Well, I'm not reading a guide, but I'll share a few links that helped me
>>> get started.  I have a Qt application and I use the SocketCAN to read/write
>>> CAN messages.  This will work with J1939 as well.
>>>
>>> https://www.kernel.org/doc/Documentation/networking/can.txt
>>> http://en.wikipedia.org/wiki/SocketCAN
>>> http://www.can-cia.org/fileadmin/cia/files/icc/13/kleine-budde.pdf
>>>
>>> On Thursday, September 11, 2014 7:44:50 PM UTC-4, William Hermans wrote:

 Brent, what guide are you reading for CAN ? I've never used CAN
 personally, and am curious . . .

 On Thu, Sep 11, 2014 at 2:25 PM, Brent Sink  wrote:

> Adding restart-ms did the trick! Thanks so much, I never knew that was
> even there.
>
> On Wed, Sep 10, 2014 at 8:37 PM, Devan Lai  wrote:
>
>> You can configure the controller to automatically recover from
>> bus-off conditions by setting the "restart-ms" option.
>>
>> The python-can documentation has some useful notes on socket-can and
>> bus-off conditions:
>>
>> http://python-can.readthedocs.org/en/latest/socketcan.html#can-errors
>>
>>
>> On Wednesday, September 10, 2014 9:39:21 AM UTC-7, Brent wrote:
>>>
>>> I have noticed that if I short CAN_H and CAN_L together, or if there
>>> is noise on the bus, the BeagleBone will stop sending and receiving CAN
>>> messages.  When this happens, if I execute "ifconfig can0 down" and
>>> "ifconfig can0 up", things start working again.  Is there a way to 
>>> detect
>>> this automatically and recover?  I'm using SocketCAN, but haven't found
>>> anything that would tell me when I get a bus off or bus heavy.
>>>
>>  --
>> 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/SdvoxYkgagc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> -brent
>
> --
> 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.
>>>
>>
>>  --
>> 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/SdvoxYkgagc/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.
>>
>
>
>
> --
> -brent
>
> --
> 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

Re: [beagleboard] Building kernel 3.14.17-ti-r19

[Charles Steinkuehler]

On 9/16/2014 2:23 PM, Jason Kridner wrote:
> On Tue, Sep 16, 2014 at 11:55 AM, Charles Steinkuehler
>  wrote:

>> What I'm working on is adding a setting to the pinmux helper, so rather
>> than trying to have the LCD cape "own" the pinmux setting, it would just
>> let the pinmux helper know it should start in a specific mode.
> 
> In general, I prefer leaving the pinmux helper in control, but I think
> *some* of the lines might be *ok* to put under control of the LCD, no?

As Robert showed, the pinmux helper can easily be disabled for
particular pins, allowing them to be directly "owned" by the driver (and
making them difficult or impossible to change w/o DT overlays or
changesets).

If you want to leave pinmux in control, one needs faith in the end users
and some "enlightenment" of the config-pin utility is in order to help
keep folks from shooting themselves in the foot.  Any pins not needing
to be modified by user-space (ie: signals that don't go to the P8/P9
headers) can probably remain under control of the appropriate driver w/o
issue.

I've got a modified version of the pinmux-helper, device-tree, and
config-pin that allow modifying the i2c2 lines after boot.  Give me a
bit to get everything organized and pushed to github (three patch-sets
to push...ugh!) and I'll post an RFC.

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Build a QT/11 application for beagleboard black by cross compiling from ubuntu

[Mirko Fucci]

Hi Peter,

apologise for the delay, at the end I decided to develop for linuxfb cross
compiling QT embedded.
However in one of my attempts i had succesfull compiled QT for X-server and
the application run in X environment. I didn't need to solve X server
dependencies in this case but i really couldn't find the right
configuration i used to compile QT, sorry.

Mirko

2014-09-10 16:21 GMT+02:00 Peter Gregory :

> Hi Mirko,
>
> How did you get rid of the X server dependencies?
> I'm using QT Creator.  Building a new QT application seems to require X
> server.
> On a headless version of Ubuntu 14.04 I can get the pre-compiled demos to
> work using -platform linuxfb
> However, my custom compiled code bombs out trying to start X server.
> Is there a special way to build the project to target linuxfb?
>
> --
> 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/mb1R6NF5RH4/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.

[beagleboard] Installing Kali Linux (Arm) onto BeagleBone Black Rev C

[macubergeekster]

Would anyone know of a set of instructions on how to install Kali to the 
BeagleBone Black Rev C?

-- 
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: BBB & MultiCast

[Brandon I]

First google result seems useful:

http://stackoverflow.com/questions/16374670/why-i-can-not-disable-multicast-request

On Tuesday, September 16, 2014 7:14:10 AM UTC-7, Mickae1 wrote:
>
> I've tried to deactivate the Multicast with :
>
> ifconfig eth0 -multicast
>
> But when i check with this command, I can still see :
>
> ip maddr show
>
> 2:  eth0
> link  33:33:00:00:00:01
> link  01:00:5e:00:00:01
> link  33:33:ff:9a:05:07
> *inet  224.0.0.1*
> inet6 ff02::1:ff9a:507
> inet6 ff02::1
>
>
> Which is not good for me !
>
>
> i've tried :
>
> debian@beaglebone:/Distrib/Scripts$ sudo ip -r maddr delete 224.0.0.1 dev 
> eth0
>
> ioctl: No such file or directory
>
>
> I also tried to ping 224.0.0.1 from an another device . 
>
> And with the command tcpdump I can see that I'm receiving multicast packet 
> :
>
> debian@beaglebone:/Distrib/Scripts$ sudo tcpdump -p -i eth0 host 224.0.0.1 
> -n
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 16:09:28.679257 IP *190.190.167.1 > 224.0.0.1*: ICMP echo request, id 1, 
> seq 1913, length 40
>
>
>
>
>
> Why ? I really don't know what to do about it, My idea is to deactivate 
> multicast in the kernel build config . Does it sounds good for you ?
>
>
>
> Thank you,
>
>
> Micka.
>

-- 
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] Building kernel 3.14.17-ti-r19

[Jason Kridner]

I've been trying out
http://builds.beagleboard.org/builders/runtests/builds/39 that seems
to have several of these changes implemented...

On Tue, Sep 16, 2014 at 11:55 AM, Charles Steinkuehler
 wrote:
> On 9/16/2014 10:26 AM, Robert Nelson wrote:
>>
>> NM, found a work around..
>>
>> When we "know" what cape is installed, thus we are already building a
>> *.dtb for it, just disable the pinmux, as it's already tied to the
>> cape.
>>
>> diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
>> b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
>> index 2df34ce..138a619 100644
>> --- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
>> +++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
>> @@ -6,6 +6,12 @@
>>   * published by the Free Software Foundation.
>>   */
>>
>> +&ocp {
>> +   P9_27_pinmux {
>> +   status = "disabled";
>> +   };
>> +};
>> +
>>  &lcdc {
>> status = "okay";
>>  };
>
> Yes, that's what you need to do for now, and this is why no "cape" pins
> can be controlled at run-time without using a device-tree overlay (or
> changeset).
>
> What I'm working on is adding a setting to the pinmux helper, so rather
> than trying to have the LCD cape "own" the pinmux setting, it would just
> let the pinmux helper know it should start in a specific mode.

In general, I prefer leaving the pinmux helper in control, but I think
*some* of the lines might be *ok* to put under control of the LCD, no?

>
> ...but it looks like you might be assigning LEDs to the GPIO.  This
> causes the GPIO pin to be "owned" by the gpio-leds driver, making it
> impossible to use the pin as a GPIO for any other purpose.  I haven't
> worked out a solution for this, other than to not use the kernel
> gpio-leds driver (driving the LED from userspace) or just give up the
> option to reconfigure the I/O and let the kernel LED driver "own" it.

For normalcy, do we agree then to put everything possible into a
pinmux helper and simply impact the boot-up state of the helper?

I see one conflict here that needs to be resolved:
[   12.785659] pinctrl-single 44e10800.pinmux: pin 44e109ac.0 already
requested by P9_25_pinmux.30; cannot claim for 48038000.mcasp
[   12.798203] pinctrl-single 44e10800.pinmux: pin-107
(48038000.mcasp) status -22
[   12.806053] pinctrl-single 44e10800.pinmux: could not request pin
107 (44e109ac.0) from group mcasp0_pins  on device pinctrl-single
[   12.818665] davinci-mcasp 48038000.mcasp: Error applying setting,
reverse things back

Any idea why there isn't a status entry on the cape-universal node?
root@beaglebone:~# ls /sys/devices/ocp.3/cape-universal.41/
modalias  power  subsystem  uevent

Full boot log: http://pastebin.com/JJkRic8h

BTW, this build seems to have resolved the funny P9_14 issue being
associated with the uSD card.

>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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] SD card issue with beaglebone black

[William Hermans]

sanjay, uEnv.txt should not have to change at all, content wise. Everything
in this file just "tells" uboot where:

1)  to load the kernel, and board file for the BBB

2) where the root file system is.

3) Lastly, optargs=quite means to be less verbose with kernel debug output
( I believe )

On Tue, Sep 16, 2014 at 11:38 AM, sanjay ahuja 
wrote:

> Basically what should be content of uEnv.txt if we are mounting external
> SD card with partition type 'ext4'?
>
>
> On Tuesday, September 16, 2014 11:43:15 PM UTC+5:30, sanjay ahuja wrote:
>>
>> Hi Robert,
>>
>> Do you have any pointer to steps for partitioning it as ext4. The link I
>> followed specifically mentioned that partition type must be 'FAT'. The
>> content of uEnv.txt as provided there is
>> mmcdev=1
>> bootpart=1:2
>> mmcroot=/dev/mmcblk1p2 ro
>> optargs=quiet
>>
>> Would it remain same if partition type is 'ext4' or some values would
>> change?
>>
>> On Tue, Sep 16, 2014 at 8:58 PM, Robert Nelson 
>> wrote:
>>
>>> On Tue, Sep 16, 2014 at 10:22 AM, sanjay ahuja
>>>  wrote:
>>> > Hi,
>>> >
>>> > I tried using microSD card as extra storage for my beaglebone black. I
>>> > followed the steps as mentioned at
>>> > http://elinux.org/Beagleboard:MicroSD_As_Extra_Storage.
>>> >
>>> > I was able to use mount microSD card successfully. However I am facing
>>> some
>>> > strange issue.
>>> >
>>> > when I do ls -lart on the mounted drive the permissions are
>>> >
>>> > drwx--  5 root root 16384 Jan  1  1970 drive
>>> >
>>> >
>>> > If I try chmod o+rx,g+rx /media/drive, to change the permissions, it
>>> does
>>> > not work. No error on issuing chmod command but permission does not get
>>> > change.
>>> >
>>> > Infact I am not even able to change the user permission for any
>>> executable
>>> > file under directory 'drive'.
>>> >
>>> > For ex.
>>> > bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
>>> > -rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/
>>> java
>>> >
>>> > bash-4.2# chmod u+x /media/drive/jdk1.7.0_60/bin/java
>>> >
>>> > bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
>>> > -rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/
>>> java
>>> >
>>> > Since 'x' permission is missing, I am not able to execute any binary
>>> file. I
>>> > am logged in as root user only. The jdk directory is expanded from jdk
>>> > installer zip using command
>>> > tar -xvf Downloads/jdk-7u60-linux-arm-vfp-sflt --owner root --group
>>> root
>>> > --no-same-owner.
>>> >
>>> > No issues are encountered if the jdk directory is expanded under home
>>> > directory instead of SD card.
>>> >
>>> > The partition details for SD Card:
>>> >
>>> > Usage : Filesystem
>>> > Partition type: W95 FAT16 (LBA) (0x0e)
>>> > Type: FAT (16-bit version)
>>> > Device: /device/mmcblk1p1
>>> > Mount Point: Mounted at /media/drive
>>>
>>> re-partition it as "ext4"... fat16 doesnt' support user permissions..
>>>
>>> Regards,
>>>
>>> --
>>> Robert Nelson
>>> http://www.rcn-ee.com/
>>>
>>> --
>>> 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/BGri5BFH2W4/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.

[beagleboard] Re: Adafruit serial UART library seems to have wrong tty names

[cl]

Michel Lavoie  wrote:
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 71 lines --]
> 
> Sorry, I didn't notice that Adafruit took care of exporting the overlays. 
> Can't help with UART3 and 5 not working, I've only used 0, 1 and 2 so far.
> 
How do you use 0 (zero), that would suit me well as it uses the header
that's not part of P8 or P9.

-- 
Chris Green
·

-- 
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: Can I *prevent* BBB from booting from microSD?

[Gerald Coley]

It is.

Gerald

On Tue, Sep 16, 2014 at 1:53 PM,  wrote:

> John Syn  wrote:
> >
> > On 9/16/14, 3:00 AM, "c...@isbd.net"  wrote:
> >
> > >I have a rev A6 (I think) BBB with the 2Gb eMMC memory.  I installed a
> > >microSd card with Ubuntu on it and it has been booting from that quite
> > >happily for the past few months.
> > >
> > >I now seem to have currupted the Ubuntu image on the microSD card such
> > >that it no longer boots successfully.  If I remove the microSD then
> > >the BBB boots OK from the eMMC into Angstrom.
> > >
> > >Is there any way I can force the BBB to boot from eMMC even though
> > >there's a microSD card plugged in?  I want to recover some files from
> > >the microSD card and I'm away from home and don't have any other means
> > >of reading the microSD.
> > >
> > >I do also have a revC BBB here but I guess that isn't going to act any
> > >differently from the older one.
> > Boot up Angstrom and then insert your SDCard. Use dmesg to confirm the
> > card was recognized and then mount the SDCard.
> >
> So it's safe to insert the SD card into a powered up system is it?
>
> --
> Chris Green
> ·
>
> --
> 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] Re: prussdrv to remoteproc

[William Hermans]

Kumar, thank you very much for your reply.

It seems as though I may need to take the time to read through your project
brief, and possibly code to get a rough idea of use case - And if it is
suitable for me. Quite honestly, I'm not even sure yet what I'd use a PRU
for in a project. This is to say, I know what a PRU *is*, I know what a PRU
is capable of ( mostly ), and how some have put it to use.

I do have one project in mind which requires high speed PWM / ADC - Think
up to around 2MHz / 2msps. However the more I think about the project, the
more I think the BBB, and both PRUs are not as suitable as something  lIke
a TI C2000 ( Delfino ).

Still, the "idea" of remoteproc is still very interesting to me. I'll
definitely do some reading on the subject.

Thanks again for your reply.

-- 
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] BBB won't change IP address

[cl]

I am having trouble getting my BBB to change its IP address.  It's on
a LAN subnet 192.168.13.0 and when first configured the DHCP server
gave it address 192.168.13.102.  It refuses to chage from 192.168.13.102
even though the DHCP server is now giving it a different address.

Has anyone else ever seen this sort of behaviour?

I only have ssh access to the BBB, no GUI.

-- 
Chris Green
·

-- 
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: Can I *prevent* BBB from booting from microSD?

[cl]

John Syn  wrote:
> 
> On 9/16/14, 3:00 AM, "c...@isbd.net"  wrote:
> 
> >I have a rev A6 (I think) BBB with the 2Gb eMMC memory.  I installed a
> >microSd card with Ubuntu on it and it has been booting from that quite
> >happily for the past few months.
> >
> >I now seem to have currupted the Ubuntu image on the microSD card such
> >that it no longer boots successfully.  If I remove the microSD then
> >the BBB boots OK from the eMMC into Angstrom.
> >
> >Is there any way I can force the BBB to boot from eMMC even though
> >there's a microSD card plugged in?  I want to recover some files from
> >the microSD card and I'm away from home and don't have any other means
> >of reading the microSD.
> >
> >I do also have a revC BBB here but I guess that isn't going to act any
> >differently from the older one.
> Boot up Angstrom and then insert your SDCard. Use dmesg to confirm the
> card was recognized and then mount the SDCard.
> 
So it's safe to insert the SD card into a powered up system is it?

-- 
Chris Green
·

-- 
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: Reading analog inputs fast in beaglebone black

[mahmoud-ashi]

Hello sir, I was following your steps but I got an error in the last step. 
I created a file in 
"bbb_fbc-0.0.2/FB_prussdrv-0.0/libpruio-0.0.2/libpruio/src/c_wrapper" and 
named it "bbb-io.c" and pasted the code you wrote. I then created another 
file named it "Makefile" and pasted "all: bbb-io.c Makefile
gcc -Wall -o bbb-io bbb-io.c /usr/local/lib/freebasic/fbrt0.o 
-lpruio -L"/usr/local/lib/freebasic/" -lfb -lpthread -lprussdrv -ltermcap 
-lsupc++ -Wno-unused-variable" in it. after running "make" command, I got 
the following:

/usr/bin/ld: cannot find -lncurses
collect2: ld returned 1 exit status
make: *** [all] Error 1

Any ideas how to solve it? I'm running "Linux beaglebone 3.8.13-bone50 #1 
SMP Tue May 13 13:24:52 UTC 2014 armv7l GNU/Linux" on my beaglebone black.
I am setting the libpruio library to read from the all the 7 analog pins 
with a sampling rate of 40KHz at least for each pin. You're help os 
appreciated. Thanks.
On Sunday, June 22, 2014 1:39:56 AM UTC+3, Rafael Vega wrote:
>
> Here's what I did:
>
>
> 1. Install FreeBasic compiler in BBB
>
> 1.1. Download package from 
> http://www.freebasic-portal.de/downloads/fb-on-arm/bbb-fbc-fbc-fuer-beaglebone-black-283.html
>
>wget http://www.freebasic-portal.de/dlfiles/452/bbb_fbc-0.0.2.tar.xz
>
> 1.2. Uncompress and copy files
>
>cd bbb_fbc-0.0.2
>cp usr/local/bin/fbc /usr/local/bin/
>cp -R usr/local/lib/freebasic /usr/local/lib/
>
> 2. Install pruss driver kit for freebasic and BBB.
>
> 2.1. Download and uncompress package from 
> http://www.freebasic-portal.de/dlfiles/539/FB_prussdrv-0.0.tar.bz2
>
> 2.2. Copy files
>
>cd FB_prussdrv-0.0
>cp bin/libprussdrv.* /usr/local/lib
>ldconfig
>mkdir /usr/local/include/freebasic/BBB
>cp include/* /usr/local/include/freebasic/BBB
>cp bin/pasm/usr/local/bin
>cp bin/PRUSSDRV-00A0.dtbo /lib/firmware
>
> 2.3. Install am335x-pru-package 
>
>apt-get install am335x-pru-package  
>
> 2.4. Activate the PRUSS by enabling the tree overlay. This must be done 
> everytime, after each boot or before running your programs. 
>
>echo PRUSSDRV> /sys/devices/bone_capemgr.9/slots
>
> 3. Install libpruio
>
> 3.1. Download and uncompress package from 
> http://www.freebasic-portal.de/dlfiles/554/libpruio-0.0.2.tar.bz2
>
> 3.2. Copy files
>
>cd libpruio-0.0.2
>cd src/c_wrapper/
>cp libpruio.so /usr/local/lib
>cp libpruio.a /usr/local/lib
>ldconfig
>cd ../pruio/
>cp pruio.bi /usr/local/include/freebasic/BBB
>cp pruio.hp /usr/local/include/freebasic/BBB
>cp pruio_pins.bi /usr/local/include/freebasic/BBB
>
> 4. Here's a simple example C program that uses the library
>
>#include 
>#include 
>#include "pruio_c_wrapper.h"
>#include "pruio_pins.h"
>
>int main(int argc, const char *argv[]) { 
>   PruIo *io = pruio_new(0, 0x98, 0, 1);
>   if (io->Errr) {
>  printf("Initialisation failed (%s)\n", io->Errr);
>  return 1;
>   }
>
>   if(pruio_config(io, 0, 0x1FE, 0, 4, 0)){
>  printf("Config failed (%s)\n", io->Errr); 
>  return 1;
>   }
>
>   int a = 0;
>   int i;
>   while(1){
>  printf("\r%12o  %12o  %12o  %12o  %4X %4X %4X %4X %4X %4X %4X 
> %4X\n", io->Gpio[0].Stat, io->Gpio[1].Stat, io->Gpio[2].Stat, 
> io->Gpio[3].Stat, io->Value[1], io->Value[2], io->Value[3], io->Value[4], 
> io->Value[5], io->Value[6], io->Value[7], io->Value[8]);
>  fflush(STDIN_FILENO);
>  usleep(1000);
>}
>
>
>   pruio_destroy(io);
>
>return 0;
>}
>
> 5. To compile it, here's a makefile:
>
>all: bbb-io.c Makefile
> gcc -Wall -o bbb-io bbb-io.c /usr/local/lib/freebasic/fbrt0.o 
> -lpruio -L"/usr/local/lib/freebasic/" -lfb -lpthread -lprussdrv -ltermcap 
> -lsupc++ -Wno-unused-variable
>
>
>
>
>
>

-- 
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] SD card issue with beaglebone black

[sanjay ahuja]

Basically what should be content of uEnv.txt if we are mounting external SD 
card with partition type 'ext4'?

On Tuesday, September 16, 2014 11:43:15 PM UTC+5:30, sanjay ahuja wrote:
>
> Hi Robert,
>
> Do you have any pointer to steps for partitioning it as ext4. The link I 
> followed specifically mentioned that partition type must be 'FAT'. The 
> content of uEnv.txt as provided there is
> mmcdev=1
> bootpart=1:2
> mmcroot=/dev/mmcblk1p2 ro
> optargs=quiet
>
> Would it remain same if partition type is 'ext4' or some values would 
> change?
>
> On Tue, Sep 16, 2014 at 8:58 PM, Robert Nelson  
> wrote:
>
>> On Tue, Sep 16, 2014 at 10:22 AM, sanjay ahuja
>>  wrote:
>> > Hi,
>> >
>> > I tried using microSD card as extra storage for my beaglebone black. I
>> > followed the steps as mentioned at
>> > http://elinux.org/Beagleboard:MicroSD_As_Extra_Storage.
>> >
>> > I was able to use mount microSD card successfully. However I am facing 
>> some
>> > strange issue.
>> >
>> > when I do ls -lart on the mounted drive the permissions are
>> >
>> > drwx--  5 root root 16384 Jan  1  1970 drive
>> >
>> >
>> > If I try chmod o+rx,g+rx /media/drive, to change the permissions, it 
>> does
>> > not work. No error on issuing chmod command but permission does not get
>> > change.
>> >
>> > Infact I am not even able to change the user permission for any 
>> executable
>> > file under directory 'drive'.
>> >
>> > For ex.
>> > bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
>> > -rw-r--r-- 1 root root 5822 May  7 20:26 
>> /media/drive/jdk1.7.0_60/bin/java
>> >
>> > bash-4.2# chmod u+x /media/drive/jdk1.7.0_60/bin/java
>> >
>> > bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
>> > -rw-r--r-- 1 root root 5822 May  7 20:26 
>> /media/drive/jdk1.7.0_60/bin/java
>> >
>> > Since 'x' permission is missing, I am not able to execute any binary 
>> file. I
>> > am logged in as root user only. The jdk directory is expanded from jdk
>> > installer zip using command
>> > tar -xvf Downloads/jdk-7u60-linux-arm-vfp-sflt --owner root --group root
>> > --no-same-owner.
>> >
>> > No issues are encountered if the jdk directory is expanded under home
>> > directory instead of SD card.
>> >
>> > The partition details for SD Card:
>> >
>> > Usage : Filesystem
>> > Partition type: W95 FAT16 (LBA) (0x0e)
>> > Type: FAT (16-bit version)
>> > Device: /device/mmcblk1p1
>> > Mount Point: Mounted at /media/drive
>>
>> re-partition it as "ext4"... fat16 doesnt' support user permissions..
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> http://www.rcn-ee.com/
>>
>> --
>> 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/BGri5BFH2W4/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] Can I *prevent* BBB from booting from microSD?

[John Syn]

On 9/16/14, 3:00 AM, "c...@isbd.net"  wrote:

>I have a rev A6 (I think) BBB with the 2Gb eMMC memory.  I installed a
>microSd card with Ubuntu on it and it has been booting from that quite
>happily for the past few months.
>
>I now seem to have currupted the Ubuntu image on the microSD card such
>that it no longer boots successfully.  If I remove the microSD then
>the BBB boots OK from the eMMC into Angstrom.
>
>Is there any way I can force the BBB to boot from eMMC even though
>there's a microSD card plugged in?  I want to recover some files from
>the microSD card and I'm away from home and don't have any other means
>of reading the microSD.
>
>I do also have a revC BBB here but I guess that isn't going to act any
>differently from the older one.
Boot up Angstrom and then insert your SDCard. Use dmesg to confirm the
card was recognized and then mount the SDCard.

Regards,
John
>
>-- 
>Chris Green
>·
>
>-- 
>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] SD card issue with beaglebone black

[sanjay ahuja]

Hi Robert,

Do you have any pointer to steps for partitioning it as ext4. The link I
followed specifically mentioned that partition type must be 'FAT'. The
content of uEnv.txt as provided there is
mmcdev=1
bootpart=1:2
mmcroot=/dev/mmcblk1p2 ro
optargs=quiet

Would it remain same if partition type is 'ext4' or some values would
change?

On Tue, Sep 16, 2014 at 8:58 PM, Robert Nelson 
wrote:

> On Tue, Sep 16, 2014 at 10:22 AM, sanjay ahuja
>  wrote:
> > Hi,
> >
> > I tried using microSD card as extra storage for my beaglebone black. I
> > followed the steps as mentioned at
> > http://elinux.org/Beagleboard:MicroSD_As_Extra_Storage.
> >
> > I was able to use mount microSD card successfully. However I am facing
> some
> > strange issue.
> >
> > when I do ls -lart on the mounted drive the permissions are
> >
> > drwx--  5 root root 16384 Jan  1  1970 drive
> >
> >
> > If I try chmod o+rx,g+rx /media/drive, to change the permissions, it does
> > not work. No error on issuing chmod command but permission does not get
> > change.
> >
> > Infact I am not even able to change the user permission for any
> executable
> > file under directory 'drive'.
> >
> > For ex.
> > bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
> > -rw-r--r-- 1 root root 5822 May  7 20:26
> /media/drive/jdk1.7.0_60/bin/java
> >
> > bash-4.2# chmod u+x /media/drive/jdk1.7.0_60/bin/java
> >
> > bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
> > -rw-r--r-- 1 root root 5822 May  7 20:26
> /media/drive/jdk1.7.0_60/bin/java
> >
> > Since 'x' permission is missing, I am not able to execute any binary
> file. I
> > am logged in as root user only. The jdk directory is expanded from jdk
> > installer zip using command
> > tar -xvf Downloads/jdk-7u60-linux-arm-vfp-sflt --owner root --group root
> > --no-same-owner.
> >
> > No issues are encountered if the jdk directory is expanded under home
> > directory instead of SD card.
> >
> > The partition details for SD Card:
> >
> > Usage : Filesystem
> > Partition type: W95 FAT16 (LBA) (0x0e)
> > Type: FAT (16-bit version)
> > Device: /device/mmcblk1p1
> > Mount Point: Mounted at /media/drive
>
> re-partition it as "ext4"... fat16 doesnt' support user permissions..
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>
> --
> 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/BGri5BFH2W4/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] Re: Beaglebone Black Rebooting Several Times Every Day

[Gerald Coley]

Thank you!

Gerald

On Tue, Sep 16, 2014 at 12:59 PM, Robert Nelson 
wrote:

> On Tue, Sep 16, 2014 at 12:56 PM, Gerald Coley 
> wrote:
> > Well. That would be nice to have everywhere.
>
> It is all the "bone" branches, except in the new 3.14-ti tree...  It
> was one of those, I was just tagging a new release, oh crap, should
> have added that. But was in a race to leave work today to run some
> errands. ;)  It'll be the first thing i add back later.
>
> Regards,
>
> --
> Robert Nelson
> http://www.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] Re: Beaglebone Black Rebooting Several Times Every Day

[Robert Nelson]

On Tue, Sep 16, 2014 at 12:56 PM, Gerald Coley  wrote:
> Well. That would be nice to have everywhere.

It is all the "bone" branches, except in the new 3.14-ti tree...  It
was one of those, I was just tagging a new release, oh crap, should
have added that. But was in a race to leave work today to run some
errands. ;)  It'll be the first thing i add back later.

Regards,

-- 
Robert Nelson
http://www.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] Lost USB networking with my Mac. What happened? How can I fix?

[Chad Baker]

Bill,
That happens to me whenever I need to get a lab put together.
Open "Network Preferences". You will probably see several "Beaglebone Black n" 
entries.
Delete every last one of those and then click "Apply".
Now click the "+" button and select BeagleBoneBlack for the Interface, 
change the service name to your choice (or not), and click "Create", and click 
"Apply".
And if you have been very good today, your BeagleBone Black will magically be 
connected.
Chad

Chad Baker
Professor Emeritus
Christian Brothers University
Electrical and Computer Engineering
Memphis, TN


On Sep 15, 2014, at 12:11 AM, b...@velkess.com wrote:

> Hello.
> 
> I've been playing around with the BBB for a while now.
> 
> All of a sudden I am not able to connect to the BBB via the USB networking 
> interface at 192.168.7.2?
> 
> I'm really not sure what happened.
> 
> I am (was!) interfacing with the BBB via my Mac laptop.
> 
> Here is what I have tried to do so far to resolve the issue.
> 
> 1) clean flash of BBB with latest Debian image
> 2) Remove FTDI and HoRNDIS drivers, reboot, and reinstall drivers.
> 
> Interestingly the BBB is showing up as a removable hard drive, and I am able 
> to successfully install the drivers off of it, so I know that the physical 
> connection is operating.  Still, there is *nothing* showing up in the System 
> Preferences->Networking window...?
> 
> I am able to get into the BBB via the ethernet jack, but I really want (if 
> not 100% need) to use the USB networking features.
> 
> Any suggestions welcome.
> 
> Thank you,
> 
> 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.

-- 
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 Rebooting Several Times Every Day

[Gerald Coley]

Well. That would be nice to have everywhere.

Gerald


On Tue, Sep 16, 2014 at 12:00 PM, Robert Nelson 
wrote:

> On Tue, Sep 16, 2014 at 11:53 AM, Chris Morgan  wrote:
> > On Tue, Sep 16, 2014 at 11:42 AM, Thomas Olofsson 
> wrote:
> >> Greg we are experiencing the same issues as well with reset not
> bringing up
> >> the eth0 interface. we were trying to do a hw watchdog that would reset
> the
> >> board and when we press reset the eth0 interface fails as well. We are
> also
> >> setting the interface config static in /etc/network/interfaces.
> >>
> >>
> >>
> >>
> >> --Skjortan!
> >>
> >> On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley 
> wrote:
> >>>
> >>> I just changed over to the Switching Power Supply and eth0 failed to
> come
> >>> up on boot. I hit the reset button and a reboot brought it up. So now
> it
> >>> seems there are eth0 issues as well as resets. Going from bad to worse.
> >>>
> >>> --
> >>> For more options, visit http://beagleboard.org/discuss
> >>> ---
> >
> >
> > I very much appreciate your efforts in looking at these issues. The
> > company I work for is planning to use a BBB in a commercial product,
> > after discussions with CircuitCo, and this issue has me a little bit
> > worried. We haven't had a wide enough scale usage to know if we are
> > seeing something similar here with the resets and eth0 issues.
> >
> > Looking forward to observing as you guys continue to work through this
> stuff.
>
> we do have a phy workaround:
>
>
> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.16/patches/beaglebone/phy/0003-cpsw-search-for-phy.patch
>
> i need to rebase it to the 3.14-ti tree..
>
> Regards,
>
> --
> Robert Nelson
> http://www.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.

[beagleboard] Re: Adafruit serial UART library seems to have wrong tty names

[Michel Lavoie]

Sorry, I didn't notice that Adafruit took care of exporting the overlays. 
Can't help with UART3 and 5 not working, I've only used 0, 1 and 2 so far.

Michel

On Tuesday, September 16, 2014 6:48:57 AM UTC-4, c...@isbd.net wrote:
>
> Michel Lavoie > wrote: 
> > [-- text/plain, encoding quoted-printable, charset: UTF-8, 81 lines --] 
> > 
> > I strongly recommend that you read Adafruit's guide regarding the BBB's 
> > device tree overlay. It really help me put this all together: 
> > 
> https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview
>  
> > 
> > You will find there why and how to modify your uEnv.txt file in order to 
> > enable ttyO1. In mine, the last line looks like this: 
> > 
> > ... 
> > optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0 
> > 
> > optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0 
> > 
> > optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0 
> > 
> > optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0 
> > 
> > 
> The Adafruit UART IO documentation specifically says that it *does* 
> export the overlays:- 
>
> The Adafruit IO Python library will export the UART device tree 
> overlays as a convenience. There are five serial ports brought to 
> the expansion headers (UART3 only has a single direction, TX), and 
> one (UART0) with dedicated headers that aren't available to use in 
> your Python programs. 
>
> ... but not all the UARTs work. 
>
> In addition the use of the letter O in the device name is just silly! :-) 
>
> The devices it creates are called /dev/ttyO1, /dev/ttyO2, etc. with 
> the letter O.  There's not a mention anywhere that it's a letter 
> rather than a digit and given the context it's second nature to assume 
> it's a zero.  Still I did spot that eventually. 
>
> -- 
> Chris Green 
> · 
>
>

-- 
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 Rebooting Several Times Every Day

[Robert Nelson]

On Tue, Sep 16, 2014 at 11:53 AM, Chris Morgan  wrote:
> On Tue, Sep 16, 2014 at 11:42 AM, Thomas Olofsson  wrote:
>> Greg we are experiencing the same issues as well with reset not bringing up
>> the eth0 interface. we were trying to do a hw watchdog that would reset the
>> board and when we press reset the eth0 interface fails as well. We are also
>> setting the interface config static in /etc/network/interfaces.
>>
>>
>>
>>
>> --Skjortan!
>>
>> On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley  wrote:
>>>
>>> I just changed over to the Switching Power Supply and eth0 failed to come
>>> up on boot. I hit the reset button and a reboot brought it up. So now it
>>> seems there are eth0 issues as well as resets. Going from bad to worse.
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>
>
> I very much appreciate your efforts in looking at these issues. The
> company I work for is planning to use a BBB in a commercial product,
> after discussions with CircuitCo, and this issue has me a little bit
> worried. We haven't had a wide enough scale usage to know if we are
> seeing something similar here with the resets and eth0 issues.
>
> Looking forward to observing as you guys continue to work through this stuff.

we do have a phy workaround:

https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.16/patches/beaglebone/phy/0003-cpsw-search-for-phy.patch

i need to rebase it to the 3.14-ti tree..

Regards,

-- 
Robert Nelson
http://www.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] Re: Beaglebone Black Rebooting Several Times Every Day

[Gerald Coley]

I plan to address this on the Ethernet issue in the next revision of the
board in the form of a GPIO based recovery mechanism that will allow SW to
reset the Ethernet PHY.

Gerald


On Tue, Sep 16, 2014 at 11:53 AM, Chris Morgan  wrote:

> On Tue, Sep 16, 2014 at 11:42 AM, Thomas Olofsson 
> wrote:
> > Greg we are experiencing the same issues as well with reset not bringing
> up
> > the eth0 interface. we were trying to do a hw watchdog that would reset
> the
> > board and when we press reset the eth0 interface fails as well. We are
> also
> > setting the interface config static in /etc/network/interfaces.
> >
> >
> >
> >
> > --Skjortan!
> >
> > On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley 
> wrote:
> >>
> >> I just changed over to the Switching Power Supply and eth0 failed to
> come
> >> up on boot. I hit the reset button and a reboot brought it up. So now it
> >> seems there are eth0 issues as well as resets. Going from bad to worse.
> >>
> >> --
> >> For more options, visit http://beagleboard.org/discuss
> >> ---
>
>
> I very much appreciate your efforts in looking at these issues. The
> company I work for is planning to use a BBB in a commercial product,
> after discussions with CircuitCo, and this issue has me a little bit
> worried. We haven't had a wide enough scale usage to know if we are
> seeing something similar here with the resets and eth0 issues.
>
> Looking forward to observing as you guys continue to work through this
> stuff.
>
> Chris
>
> --
> 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] Re: Beaglebone Black Rebooting Several Times Every Day

[Chris Morgan]

On Tue, Sep 16, 2014 at 11:42 AM, Thomas Olofsson  wrote:
> Greg we are experiencing the same issues as well with reset not bringing up
> the eth0 interface. we were trying to do a hw watchdog that would reset the
> board and when we press reset the eth0 interface fails as well. We are also
> setting the interface config static in /etc/network/interfaces.
>
>
>
>
> --Skjortan!
>
> On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley  wrote:
>>
>> I just changed over to the Switching Power Supply and eth0 failed to come
>> up on boot. I hit the reset button and a reboot brought it up. So now it
>> seems there are eth0 issues as well as resets. Going from bad to worse.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---


I very much appreciate your efforts in looking at these issues. The
company I work for is planning to use a BBB in a commercial product,
after discussions with CircuitCo, and this issue has me a little bit
worried. We haven't had a wide enough scale usage to know if we are
seeing something similar here with the resets and eth0 issues.

Looking forward to observing as you guys continue to work through this stuff.

Chris

-- 
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] BBB with own cape stops working

[Gerald Coley]

The rail can drive it. No using the 3.3V rail will not cause damage to the
processor I/O pins as long as the reset lines is sued to make sure they are
not driven until reset is released..

Gerald


On Tue, Sep 16, 2014 at 11:25 AM, Ulli  wrote:

>
> Can the 3V3 supply of the Beagle drive all the components regarding max
> current?
> Could that blow the beagle like described at the beginning?
>
> Am Dienstag, 16. September 2014 18:18:25 UTC+2 schrieb Gerald:
>>
>> It has to be HW or the application and use of the hardware. Maybe you
>> have a short or some other issue with your assembly.
>>
>> Gerald
>>
>>
>> On Tue, Sep 16, 2014 at 11:13 AM, Ulli  wrote:
>>
>>> @Gerald: What else can be wrong except the hardware design?
>>>
>>> Am Montag, 15. September 2014 23:25:11 UTC+2 schrieb Ulli:
>>>

 I am not sure what you mean with "to disable the buffer before until
 you come up".
 Directly connect the Beagle SYS_RESETn pin to the pin 29 of the
 Atmega`s?

 What would be the positive effect by using the SYS_5V. I think it is
 directly connected to the Beagle DC plug. So, it can drive more current?

 Two more ideas:
  * would it be helpful to add a 0,1µF capacitor to the beagle voltage
 supply pins on the header, between VDD_3v3 and Gnd very close to the beagle
 headers?
  * would it be better to completely supply my cape from SYS_5V and
 create the 3v for the Atmegas and the other components on the cape with the
 MCP1703?

 Am Montag, 15. September 2014 23:14:45 UTC+2 schrieb Gerald:
>
> Nothing else jumps out at me. The 5V rail you are using is on before
> the board is powered up, but I don't think that should matter. You could
> switch to SYS_5V, no reason not to.As you only have four wires to the BBB,
> you might try adding some isolation there, and use the RESET signal to
> disable the buffer before until you cone up.
>
> There may be something else in your setup. But, schematic wise
> I don't see anything else.
>
> Gerald
>
>
> On Mon, Sep 15, 2014 at 4:09 PM,  wrote:
>
>> Yes of course. I added this option just to run the cape for first
>> tries on a USB port.
>>
>> Could you find any other problems? I am currently thinking to connect
>> the SYS_RESETn of the BBB directly to the reset pin of the atmega`s?
>>
>> Am Montag, 15. September 2014 23:06:09 UTC+2 schrieb Gerald:
>>>
>>> Looks like you have shorting posts for your standalone versus cape
>>> mode. If you ever by accident plug in the standalone mode into the BBB,
>>> then you will damage the board for sure.
>>>
>>> Gerald
>>>
>>>
>>> On Mon, Sep 15, 2014 at 3:51 PM, ulli  wrote:
>>>

 You are right, there must be something wrong but I do not know what.
 I understood that the blocking capacitor is missing. But I do not
 know if that is the only mistake and this is the reason why my beagle
 stopped working because of my cape

 I updated the circuit to that configuration like it is when I have
 it connected to the beagle.
 https://drive.google.com/file/d/0B8Fq4yYMgG7uTFlIRjdjcGRUYlE/
 edit?usp=sharing


 Am Montag, 15. September 2014 22:32:54 UTC+2 schrieb Gerald:
>
> So your contention is that this is all correct? Do I read you
> right?
>
> Gerald
>
>
> On Mon, Sep 15, 2014 at 3:24 PM,  wrote:
>
>> Thanks for your quick answer and very helpful feedback!
>>
>> I am not sure if I understood right.
>>
>> Currently I have to options to power the cape.
>> 1. Use the cape without the Beagle
>>--> Power supply over the FTDI connector and solder header
>> Pin2-Pin3 connected on the MCP1703 side.
>>--> 5V solder header Pin1-Pin2 connected
>>--> 3,3V will be generated with the MCP1703 from the input
>> voltage VIN
>>
>> 2. Use the cape with the Beagle
>>--> Power supply all over the beagle headers and solder header
>> Pin1-Pin2 connected on the MCP1703 side. Therefore no voltages will 
>> be
>> generated by the cape itself...
>>--> 5V solder header Pin2-Pin3 connected. 5V from the beagle.
>>--> 3,3V from the beagle
>>
>> Therefore the atmega`s can only power up when the 3.3v supply of
>> the header is available.
>> The 5v supply is always on thats right. But 5v is only used for
>> LED`s and the Piezo Buzzer and this parts are
>> disconnected with a BC817 from ground.
>>
>> Yes all wires which are named as GND are connected.
>>
>> Do you really see an issue on that? What needs to be changed?
>>
>> Am Montag, 15. September 20

Re: [beagleboard] BBB with own cape stops working

[Ulli]

Can the 3V3 supply of the Beagle drive all the components regarding max 
current?
Could that blow the beagle like described at the beginning?

Am Dienstag, 16. September 2014 18:18:25 UTC+2 schrieb Gerald:
>
> It has to be HW or the application and use of the hardware. Maybe you have 
> a short or some other issue with your assembly.
>
> Gerald
>
>
> On Tue, Sep 16, 2014 at 11:13 AM, Ulli  > wrote:
>
>> @Gerald: What else can be wrong except the hardware design?
>>
>> Am Montag, 15. September 2014 23:25:11 UTC+2 schrieb Ulli:
>>
>>>
>>> I am not sure what you mean with "to disable the buffer before until you 
>>> come up". 
>>> Directly connect the Beagle SYS_RESETn pin to the pin 29 of the Atmega`s?
>>>
>>> What would be the positive effect by using the SYS_5V. I think it is 
>>> directly connected to the Beagle DC plug. So, it can drive more current?
>>>
>>> Two more ideas:
>>>  * would it be helpful to add a 0,1µF capacitor to the beagle voltage 
>>> supply pins on the header, between VDD_3v3 and Gnd very close to the beagle 
>>> headers?
>>>  * would it be better to completely supply my cape from SYS_5V and 
>>> create the 3v for the Atmegas and the other components on the cape with the 
>>> MCP1703?
>>>
>>> Am Montag, 15. September 2014 23:14:45 UTC+2 schrieb Gerald:

 Nothing else jumps out at me. The 5V rail you are using is on before 
 the board is powered up, but I don't think that should matter. You could 
 switch to SYS_5V, no reason not to.As you only have four wires to the BBB, 
 you might try adding some isolation there, and use the RESET signal to 
 disable the buffer before until you cone up.

 There may be something else in your setup. But, schematic wise 
 I don't see anything else.

 Gerald


 On Mon, Sep 15, 2014 at 4:09 PM,  wrote:

> Yes of course. I added this option just to run the cape for first 
> tries on a USB port.
>
> Could you find any other problems? I am currently thinking to connect 
> the SYS_RESETn of the BBB directly to the reset pin of the atmega`s?
>
> Am Montag, 15. September 2014 23:06:09 UTC+2 schrieb Gerald:
>>
>> Looks like you have shorting posts for your standalone versus cape 
>> mode. If you ever by accident plug in the standalone mode into the BBB, 
>> then you will damage the board for sure.
>>
>> Gerald
>>
>>
>> On Mon, Sep 15, 2014 at 3:51 PM, ulli  wrote:
>>
>>>
>>> You are right, there must be something wrong but I do not know what.
>>> I understood that the blocking capacitor is missing. But I do not 
>>> know if that is the only mistake and this is the reason why my beagle 
>>> stopped working because of my cape
>>>
>>> I updated the circuit to that configuration like it is when I have 
>>> it connected to the beagle.
>>> https://drive.google.com/file/d/0B8Fq4yYMgG7uTFlIRjdjcGRUYlE/
>>> edit?usp=sharing
>>>
>>>
>>> Am Montag, 15. September 2014 22:32:54 UTC+2 schrieb Gerald:

 So your contention is that this is all correct? Do I read you right?

 Gerald


 On Mon, Sep 15, 2014 at 3:24 PM,  wrote:

> Thanks for your quick answer and very helpful feedback!
>
> I am not sure if I understood right.
>
> Currently I have to options to power the cape.
> 1. Use the cape without the Beagle
>--> Power supply over the FTDI connector and solder header 
> Pin2-Pin3 connected on the MCP1703 side.
>--> 5V solder header Pin1-Pin2 connected
>--> 3,3V will be generated with the MCP1703 from the input 
> voltage VIN
>
> 2. Use the cape with the Beagle
>--> Power supply all over the beagle headers and solder header 
> Pin1-Pin2 connected on the MCP1703 side. Therefore no voltages will 
> be 
> generated by the cape itself...
>--> 5V solder header Pin2-Pin3 connected. 5V from the beagle.
>--> 3,3V from the beagle
>
> Therefore the atmega`s can only power up when the 3.3v supply of 
> the header is available.
> The 5v supply is always on thats right. But 5v is only used for 
> LED`s and the Piezo Buzzer and this parts are 
> disconnected with a BC817 from ground. 
>
> Yes all wires which are named as GND are connected.
>
> Do you really see an issue on that? What needs to be changed?
>
> Am Montag, 15. September 2014 21:56:47 UTC+2 schrieb Gerald:
>>
>> Your regulator must be turned off until the VDD_3V3 rail comes 
>> up. Right now it comes up almost immediately as it is powered from 
>> either 
>> the expansion header or a weirdly designed 5V DC input. The idea of 
>> gating 
>> the ground to control powe

[beagleboard] I2C read failed : LI-5M03 + BeagleBoard-xM Rev C2

[steph]

Hi,

I have Li-5M03 rev 3.1 and BB-xM rev C2.

*root@beagleboard:~# uname -a : *

Linux beagleboard 2.6.32 #3 PREEMPT Tue Jul 26 10:56:56 CEST 2011 armv7l 
unknown

I have follow this instructions to install kernel and have a mt9p031 
working (http://caganarslan.wordpress.com/2013/07/04/second-post/).

I can take snapshot and video with :
 
*mplayer tv:// -tv 
driver=v4l2:width=1280:height=720:device=/dev/video0:fps=5 -vo jpeg*

or

*mplayer tv:// -tv 
driver=v4l2:width=640:height=480:device=/dev/video0:fps=10 -vo x11*


And it works perfectly.

 But i have a problem, i can't read/write in register with i2c-tools. I 
have tried :

*root@beagleboard:~# i2cdetect -r 2*
 
WARNING! This program can confuse your I2C bus, cause data loss and worse!

I will probe file /dev/i2c-2 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: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

70: -- -- -- -- -- -- -- -- 


Sensor is well detect on 0x48 address.


But when i tried to modify gain or exposure, i get :
 
*root@beagleboard:~# echo 22 > 
/sys/devices/platform/i2c_omap.2/i2c-2/2-0048/gain_val* 

[ 3638.106781] mt9p031 2-0048: Error setting gain.-121

[ 3638.111511] mt9p031: Global gain write failed

*root@beagleboard:~/Desktop# dmesg | grep mt9*

[ 3304.832366] mt9p031 2-0048: mt9p031 chip ID 1801

[ 3638.106781] mt9p031 2-0048: Error setting gain.-121

[ 3638.111511] mt9p031: Global gain write failed


*root@beagleboard:~/Desktop# i2cget -y 2 0x48 000 w*

Error: Could not set address to 0x48: Device or resource busy


Any ideas ?


Thank you


-- 
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] Custom Audio cape with TLV320AIC3107 codec.

[Prakash Parmar]

Hi Maxim ,

I try with your suggestion of "aplay -vv test.wav" But still same things.
Please find attachment of dmesg log.

Hope listen from you soon. :)

Thanks & Regards,
Prakash P.



On Tue, Sep 16, 2014 at 9:23 PM, Prakash Parmar 
wrote:

> Hi,
>
> Here CircuitCo cape is not available So we decided to make our own.
>
>
> On Tue, Sep 16, 2014 at 7:20 PM, Jesse Cobra  wrote:
>
>> What happens when you try the CircuitCO audio cape?
>> Does it work fine?
>>
>> On Mon, Sep 15, 2014 at 10:14 PM, Prakash Parmar <
>> prakash.parma...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> How I can check this two things ?
>>>
>>> 2) check if SYS_RESET is actually deasserted and high
>>> 3) check if DIN/DOUT are correctly connected and not flipped, because
>>> DIN data must go into CODEC, while DOUT must go out and vise versa
>>>
>>> I'm not clear about this. Actually I have two Boards one with 10K
>>> resistors and one with 4.6K .
>>>
>>> Thanks & Regards,
>>> Prakash P.
>>>
>>> On Tue, Sep 16, 2014 at 12:34 AM, Maxim Podbereznyy 
>>> wrote:
>>>
 what is exactly not clear for you?

 how to change resistors or how to copy/paste commands in a shell?

 2014-09-15 21:46 GMT+04:00 :

> HI,
> Thanks For reply.
>
> Can you please tell me how I can Do that ?
>
>
> Thanks & Regards,
> Prakash P.
>
> On Monday, September 15, 2014 8:01:19 PM UTC+5:30, liyaoshi wrote:
>>
>> Have you config the i2c pin pulled up ?
>> and
>> whats the speed of your i2c bus ?
>>
>> 2014-09-15 2:09 GMT+08:00 :
>>
>>> Hi,
>>>
>>> I have made custom Audio cape using TLV320AIC3107. Here is a circuit
>>> diagram :
>>>
>>>
>>> 
>>>
>>>
>>> I make it same  ( Pin configurations and all ) as what is available
>>> at CircuitCO using TLC320AIC3104 codec. I follow All steps like Disable
>>> HDMI and Load Device Tree BB-BONE-AUDI-02-00A0.dts  and I it works fine.
>>>
>>> But my problem is when I run speaker-test system hangs (freezes) and
>>> I have to Hard Reset BeagleBone.
>>>
>>> Here is what i did and what I get in dmesg.
>>>
>>>
>>> *root@beaglebone:~# speaker-test *
>>>
>>> speaker-test 1.0.25
>>>
>>> Playback device is default
>>> Stream parameters are 48000Hz, S16_LE, 1 channels
>>> Using 16 octaves of pink noise
>>> Rate set to 48000Hz (requested 48000Hz)
>>> Buffer size range from 128 to 32768
>>> Period size range from 8 to 2048
>>> Using max buffer size 32768
>>> Periods = 4
>>>
>>>
>>> *And in Dmesg : *
>>>
>>> [  205.540653] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  206.572921] omap_i2c 4819c000.i2c: controller timed out
>>> [  206.580024] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  207.611983] omap_i2c 4819c000.i2c: controller timed out
>>> [  207.618668] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  212.626062] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  213.658853] omap_i2c 4819c000.i2c: controller timed out
>>> [  213.666881] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  214.699867] omap_i2c 4819c000.i2c: controller timed out
>>> [  214.707912] omap_i2c 4819c000.i2c: Arbitration lost
>>> [  215.740887] omap_i2c 4819c000.i2c: controller timed out
>>> [  215.748952] omap_i2c 4819c000.i2c: Arbitration lost
>>>
>>>
>>> I also cross check device tree file and I found that it also works
>>> for TLV320AIC3107 codec So I think it is not issue.
>>>
>>> An one have Idea what is wrong Please Help ME 
>>>
>>>
>>> Thanks & Regards
>>>
>>> Prakash P.
>>>
>>>  --
>>> 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.
>



 --
 LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
 Company - http://www.linkedin.com/company/mentorel
 Facebook - https://www.facebook.com/mentorel.company

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups

[beagleboard] Re: RFM12Piv2 on BBB

[jasonwxwcn]

HI, We have turnkey solution for wireless communication. In this solution 
few code need to integrate with Beagle Board. It names RF4432.
RF4432 is an alternative for XBEE. It just needs four wire connecting with 
device when systems integrate. VCC, GND, TXD, RXD. It has much more range 
compared with XBEE. Anyway it is better than RFM12 and XRF and 
cost-effective. RF4432 transparent solution is based on Si4432 solution, 
which is 20dBm output power with line of sight range 1500m in the open. It 
provide standard UART port, which make it only need 4 wire to connect 
with Beagle Board. By the contrast , other solution such as RFM12 or XRF 
need 11 wire to connect with Beagle Board. We also can provide standard 
RS232 and RS485 port to meet any requirement. It is much convenient for the 
design. We already have built the checksum in the module like CRC, FEC, 
Manchester coding to implement the security, which users don’t need to care 
about that. When RFM12 integrate with ATmega328, engineers need to add 4 
feedback capacitance, 1 oscillator and antenna matching solution. What’s 
RF4432 need? Nothing. We provide standard SMA connector and user just screw 
up the antenna on the modules. The antenna matching determines the 
performance of RF solution. Our quotation is including the antenna price. I 
think it is an economic solution for you. 

Pls check this link for its datasheet: 
http://www.appconwireless.com/upload/file/RF4432.pdf

在 2014年1月26日星期日UTC+8上午4时19分24秒，NicoD写道：
>
> Hello
> Following this thread  I 
> learn that there is a module that is capable to receive RF433 frames.
> this module is the RFM12PIV2 from EnergyMonitor
> So, I bought, receive it
>
> after updated my BBB under Ubuntu (13.10), I recompiled the drivers for 
> this distribution (https://github.com/gkaindl/rfm12b-linux)
> According this pinout 
>  I 
> connected the module to my BBB
>
> Loading the module with the "ismod" command produces the following lines 
> in dmesg :
> [304488.785541] rfm12b: added RFM12(B) transceiver rfm12b.1.1
> [304488.787064] rfm12b : driver loaded.
> --> everything seems to be okay
>
> in lsmod the module appears as
> Module  Size  Used by
> rfm12b 14897  0 
>
> a device is now present under /dev  : /dev/rfm12b.1.1
>
> And now, I don't know where to go to get raw frames
>
>
>
> any help would be welcome
>
> thank you
>
> ps:
>
> tech infos:
>
> uname -a
> Linux BeagleBoneBlack 3.8.13-bone32 #1 SMP Fri Dec 13 20:05:25 UTC 2013 
> armv7l armv7l armv7l GNU/Linux
>
>

-- 
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] BBB with own cape stops working

[Gerald Coley]

It has to be HW or the application and use of the hardware. Maybe you have
a short or some other issue with your assembly.

Gerald


On Tue, Sep 16, 2014 at 11:13 AM, Ulli  wrote:

> @Gerald: What else can be wrong except the hardware design?
>
> Am Montag, 15. September 2014 23:25:11 UTC+2 schrieb Ulli:
>
>>
>> I am not sure what you mean with "to disable the buffer before until you
>> come up".
>> Directly connect the Beagle SYS_RESETn pin to the pin 29 of the Atmega`s?
>>
>> What would be the positive effect by using the SYS_5V. I think it is
>> directly connected to the Beagle DC plug. So, it can drive more current?
>>
>> Two more ideas:
>>  * would it be helpful to add a 0,1µF capacitor to the beagle voltage
>> supply pins on the header, between VDD_3v3 and Gnd very close to the beagle
>> headers?
>>  * would it be better to completely supply my cape from SYS_5V and create
>> the 3v for the Atmegas and the other components on the cape with the
>> MCP1703?
>>
>> Am Montag, 15. September 2014 23:14:45 UTC+2 schrieb Gerald:
>>>
>>> Nothing else jumps out at me. The 5V rail you are using is on before
>>> the board is powered up, but I don't think that should matter. You could
>>> switch to SYS_5V, no reason not to.As you only have four wires to the BBB,
>>> you might try adding some isolation there, and use the RESET signal to
>>> disable the buffer before until you cone up.
>>>
>>> There may be something else in your setup. But, schematic wise
>>> I don't see anything else.
>>>
>>> Gerald
>>>
>>>
>>> On Mon, Sep 15, 2014 at 4:09 PM,  wrote:
>>>
 Yes of course. I added this option just to run the cape for first tries
 on a USB port.

 Could you find any other problems? I am currently thinking to connect
 the SYS_RESETn of the BBB directly to the reset pin of the atmega`s?

 Am Montag, 15. September 2014 23:06:09 UTC+2 schrieb Gerald:
>
> Looks like you have shorting posts for your standalone versus cape
> mode. If you ever by accident plug in the standalone mode into the BBB,
> then you will damage the board for sure.
>
> Gerald
>
>
> On Mon, Sep 15, 2014 at 3:51 PM, ulli  wrote:
>
>>
>> You are right, there must be something wrong but I do not know what.
>> I understood that the blocking capacitor is missing. But I do not
>> know if that is the only mistake and this is the reason why my beagle
>> stopped working because of my cape
>>
>> I updated the circuit to that configuration like it is when I have it
>> connected to the beagle.
>> https://drive.google.com/file/d/0B8Fq4yYMgG7uTFlIRjdjcGRUYlE/
>> edit?usp=sharing
>>
>>
>> Am Montag, 15. September 2014 22:32:54 UTC+2 schrieb Gerald:
>>>
>>> So your contention is that this is all correct? Do I read you right?
>>>
>>> Gerald
>>>
>>>
>>> On Mon, Sep 15, 2014 at 3:24 PM,  wrote:
>>>
 Thanks for your quick answer and very helpful feedback!

 I am not sure if I understood right.

 Currently I have to options to power the cape.
 1. Use the cape without the Beagle
--> Power supply over the FTDI connector and solder header
 Pin2-Pin3 connected on the MCP1703 side.
--> 5V solder header Pin1-Pin2 connected
--> 3,3V will be generated with the MCP1703 from the input
 voltage VIN

 2. Use the cape with the Beagle
--> Power supply all over the beagle headers and solder header
 Pin1-Pin2 connected on the MCP1703 side. Therefore no voltages will be
 generated by the cape itself...
--> 5V solder header Pin2-Pin3 connected. 5V from the beagle.
--> 3,3V from the beagle

 Therefore the atmega`s can only power up when the 3.3v supply of
 the header is available.
 The 5v supply is always on thats right. But 5v is only used for
 LED`s and the Piezo Buzzer and this parts are
 disconnected with a BC817 from ground.

 Yes all wires which are named as GND are connected.

 Do you really see an issue on that? What needs to be changed?

 Am Montag, 15. September 2014 21:56:47 UTC+2 schrieb Gerald:
>
> Your regulator must be turned off until the VDD_3V3 rail comes up.
> Right now it comes up almost immediately as it is powered from either 
> the
> expansion header or a weirdly designed 5V DC input. The idea of 
> gating the
> ground to control power will not work as you already have a DC path to
> ground, assuming that all of your grounds are connected together as
> they should be.
>
> Gerald
>
> On Mon, Sep 15, 2014 at 2:45 PM,  wrote:
>
>> Oh I understood, I need to add the C1 on each Atmega 3V3 supply.
>> --> blocking
>> 

Re: [beagleboard] BBB with own cape stops working

[Ulli]

@Gerald: What else can be wrong except the hardware design?

Am Montag, 15. September 2014 23:25:11 UTC+2 schrieb Ulli:
>
>
> I am not sure what you mean with "to disable the buffer before until you 
> come up". 
> Directly connect the Beagle SYS_RESETn pin to the pin 29 of the Atmega`s?
>
> What would be the positive effect by using the SYS_5V. I think it is 
> directly connected to the Beagle DC plug. So, it can drive more current?
>
> Two more ideas:
>  * would it be helpful to add a 0,1µF capacitor to the beagle voltage 
> supply pins on the header, between VDD_3v3 and Gnd very close to the beagle 
> headers?
>  * would it be better to completely supply my cape from SYS_5V and create 
> the 3v for the Atmegas and the other components on the cape with the 
> MCP1703?
>
> Am Montag, 15. September 2014 23:14:45 UTC+2 schrieb Gerald:
>>
>> Nothing else jumps out at me. The 5V rail you are using is on before 
>> the board is powered up, but I don't think that should matter. You could 
>> switch to SYS_5V, no reason not to.As you only have four wires to the BBB, 
>> you might try adding some isolation there, and use the RESET signal to 
>> disable the buffer before until you cone up.
>>
>> There may be something else in your setup. But, schematic wise 
>> I don't see anything else.
>>
>> Gerald
>>
>>
>> On Mon, Sep 15, 2014 at 4:09 PM,  wrote:
>>
>>> Yes of course. I added this option just to run the cape for first tries 
>>> on a USB port.
>>>
>>> Could you find any other problems? I am currently thinking to connect 
>>> the SYS_RESETn of the BBB directly to the reset pin of the atmega`s?
>>>
>>> Am Montag, 15. September 2014 23:06:09 UTC+2 schrieb Gerald:

 Looks like you have shorting posts for your standalone versus cape 
 mode. If you ever by accident plug in the standalone mode into the BBB, 
 then you will damage the board for sure.

 Gerald


 On Mon, Sep 15, 2014 at 3:51 PM, ulli  wrote:

>
> You are right, there must be something wrong but I do not know what.
> I understood that the blocking capacitor is missing. But I do not know 
> if that is the only mistake and this is the reason why my beagle stopped 
> working because of my cape
>
> I updated the circuit to that configuration like it is when I have it 
> connected to the beagle.
> https://drive.google.com/file/d/0B8Fq4yYMgG7uTFlIRjdjcGRUYlE/
> edit?usp=sharing
>
>
> Am Montag, 15. September 2014 22:32:54 UTC+2 schrieb Gerald:
>>
>> So your contention is that this is all correct? Do I read you right?
>>
>> Gerald
>>
>>
>> On Mon, Sep 15, 2014 at 3:24 PM,  wrote:
>>
>>> Thanks for your quick answer and very helpful feedback!
>>>
>>> I am not sure if I understood right.
>>>
>>> Currently I have to options to power the cape.
>>> 1. Use the cape without the Beagle
>>>--> Power supply over the FTDI connector and solder header 
>>> Pin2-Pin3 connected on the MCP1703 side.
>>>--> 5V solder header Pin1-Pin2 connected
>>>--> 3,3V will be generated with the MCP1703 from the input 
>>> voltage VIN
>>>
>>> 2. Use the cape with the Beagle
>>>--> Power supply all over the beagle headers and solder header 
>>> Pin1-Pin2 connected on the MCP1703 side. Therefore no voltages will be 
>>> generated by the cape itself...
>>>--> 5V solder header Pin2-Pin3 connected. 5V from the beagle.
>>>--> 3,3V from the beagle
>>>
>>> Therefore the atmega`s can only power up when the 3.3v supply of the 
>>> header is available.
>>> The 5v supply is always on thats right. But 5v is only used for 
>>> LED`s and the Piezo Buzzer and this parts are 
>>> disconnected with a BC817 from ground. 
>>>
>>> Yes all wires which are named as GND are connected.
>>>
>>> Do you really see an issue on that? What needs to be changed?
>>>
>>> Am Montag, 15. September 2014 21:56:47 UTC+2 schrieb Gerald:

 Your regulator must be turned off until the VDD_3V3 rail comes up. 
 Right now it comes up almost immediately as it is powered from either 
 the 
 expansion header or a weirdly designed 5V DC input. The idea of gating 
 the 
 ground to control power will not work as you already have a DC path to 
 ground, assuming that all of your grounds are connected together as 
 they should be.

 Gerald

 On Mon, Sep 15, 2014 at 2:45 PM,  wrote:

> Oh I understood, I need to add the C1 on each Atmega 3V3 supply. 
> --> blocking 
> 
>  
> capacitor 
> 
> But c

Re: [beagleboard] Building kernel 3.14.17-ti-r19

[Charles Steinkuehler]

On 9/16/2014 10:26 AM, Robert Nelson wrote:
> 
> NM, found a work around..
> 
> When we "know" what cape is installed, thus we are already building a
> *.dtb for it, just disable the pinmux, as it's already tied to the
> cape.
> 
> diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> index 2df34ce..138a619 100644
> --- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> @@ -6,6 +6,12 @@
>   * published by the Free Software Foundation.
>   */
> 
> +&ocp {
> +   P9_27_pinmux {
> +   status = "disabled";
> +   };
> +};
> +
>  &lcdc {
> status = "okay";
>  };

Yes, that's what you need to do for now, and this is why no "cape" pins
can be controlled at run-time without using a device-tree overlay (or
changeset).

What I'm working on is adding a setting to the pinmux helper, so rather
than trying to have the LCD cape "own" the pinmux setting, it would just
let the pinmux helper know it should start in a specific mode.

...but it looks like you might be assigning LEDs to the GPIO.  This
causes the GPIO pin to be "owned" by the gpio-leds driver, making it
impossible to use the pin as a GPIO for any other purpose.  I haven't
worked out a solution for this, other than to not use the kernel
gpio-leds driver (driving the LED from userspace) or just give up the
option to reconfigure the I/O and let the kernel LED driver "own" it.

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Custom Audio cape with TLV320AIC3107 codec.

[Prakash Parmar]

Hi,

Here CircuitCo cape is not available So we decided to make our own.


On Tue, Sep 16, 2014 at 7:20 PM, Jesse Cobra  wrote:

> What happens when you try the CircuitCO audio cape?
> Does it work fine?
>
> On Mon, Sep 15, 2014 at 10:14 PM, Prakash Parmar <
> prakash.parma...@gmail.com> wrote:
>
>> Hi,
>>
>> How I can check this two things ?
>>
>> 2) check if SYS_RESET is actually deasserted and high
>> 3) check if DIN/DOUT are correctly connected and not flipped, because DIN
>> data must go into CODEC, while DOUT must go out and vise versa
>>
>> I'm not clear about this. Actually I have two Boards one with 10K
>> resistors and one with 4.6K .
>>
>> Thanks & Regards,
>> Prakash P.
>>
>> On Tue, Sep 16, 2014 at 12:34 AM, Maxim Podbereznyy 
>> wrote:
>>
>>> what is exactly not clear for you?
>>>
>>> how to change resistors or how to copy/paste commands in a shell?
>>>
>>> 2014-09-15 21:46 GMT+04:00 :
>>>
 HI,
 Thanks For reply.

 Can you please tell me how I can Do that ?


 Thanks & Regards,
 Prakash P.

 On Monday, September 15, 2014 8:01:19 PM UTC+5:30, liyaoshi wrote:
>
> Have you config the i2c pin pulled up ?
> and
> whats the speed of your i2c bus ?
>
> 2014-09-15 2:09 GMT+08:00 :
>
>> Hi,
>>
>> I have made custom Audio cape using TLV320AIC3107. Here is a circuit
>> diagram :
>>
>>
>> 
>>
>>
>> I make it same  ( Pin configurations and all ) as what is available
>> at CircuitCO using TLC320AIC3104 codec. I follow All steps like Disable
>> HDMI and Load Device Tree BB-BONE-AUDI-02-00A0.dts  and I it works fine.
>>
>> But my problem is when I run speaker-test system hangs (freezes) and
>> I have to Hard Reset BeagleBone.
>>
>> Here is what i did and what I get in dmesg.
>>
>>
>> *root@beaglebone:~# speaker-test *
>>
>> speaker-test 1.0.25
>>
>> Playback device is default
>> Stream parameters are 48000Hz, S16_LE, 1 channels
>> Using 16 octaves of pink noise
>> Rate set to 48000Hz (requested 48000Hz)
>> Buffer size range from 128 to 32768
>> Period size range from 8 to 2048
>> Using max buffer size 32768
>> Periods = 4
>>
>>
>> *And in Dmesg : *
>>
>> [  205.540653] omap_i2c 4819c000.i2c: Arbitration lost
>> [  206.572921] omap_i2c 4819c000.i2c: controller timed out
>> [  206.580024] omap_i2c 4819c000.i2c: Arbitration lost
>> [  207.611983] omap_i2c 4819c000.i2c: controller timed out
>> [  207.618668] omap_i2c 4819c000.i2c: Arbitration lost
>> [  212.626062] omap_i2c 4819c000.i2c: Arbitration lost
>> [  213.658853] omap_i2c 4819c000.i2c: controller timed out
>> [  213.666881] omap_i2c 4819c000.i2c: Arbitration lost
>> [  214.699867] omap_i2c 4819c000.i2c: controller timed out
>> [  214.707912] omap_i2c 4819c000.i2c: Arbitration lost
>> [  215.740887] omap_i2c 4819c000.i2c: controller timed out
>> [  215.748952] omap_i2c 4819c000.i2c: Arbitration lost
>>
>>
>> I also cross check device tree file and I found that it also works
>> for TLV320AIC3107 codec So I think it is not issue.
>>
>> An one have Idea what is wrong Please Help ME 
>>
>>
>> Thanks & Regards
>>
>> Prakash P.
>>
>>  --
>> 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.

>>>
>>>
>>>
>>> --
>>> LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
>>> Company - http://www.linkedin.com/company/mentorel
>>> Facebook - https://www.facebook.com/mentorel.company
>>>
>>> --
>>> 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/0ickf2E6NNs/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/discus

Re: [beagleboard] Re: Beaglebone Black Rebooting Several Times Every Day

[Thomas Olofsson]

Greg we are experiencing the same issues as well with reset not bringing up
the eth0 interface. we were trying to do a hw watchdog that would reset the
board and when we press reset the eth0 interface fails as well. We are also
setting the interface config static in /etc/network/interfaces.




--Skjortan!

On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley  wrote:

> I just changed over to the Switching Power Supply and eth0 failed to come
> up on boot. I hit the reset button and a reboot brought it up. So now it
> seems there are eth0 issues as well as resets. Going from bad to worse.
>
> --
> 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/vgeh336p0P4/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.

[beagleboard] Re: PWM: changing Period of EHRPWM

[avterekhov]

Hi,

In case someone still needs a solution to this problem, I've written a 
small kernel patch: ti_ehr_pwm.patch 
 and a short 
description of how to apply it: 
https://randomlinuxhacks.wordpress.com/2014/09/16/changing-pwm-period-on-beaglebone-black/

So far it works for me.

On Thursday, June 26, 2014 8:10:26 AM UTC+2, jmc...@gmail.com wrote:
>
> I also tried this and had no luck :-/
>
> PWM on the BBB is turning out to be more work than I had thought.
>
> On Monday, January 6, 2014 12:13:37 PM UTC-8, Anto Dominic wrote:
>>
>> Thanks,
>>
>> Tried your trick even replaced the new dtbo file but even after 
>> that I am getting the default value for Period ( ie, 500) and duty (ie, 
>> 0) ... Is there any step that you missed in between...??. Anyways thanks 
>> for the tip..:)
>>
>> On Monday, 8 July 2013 08:44:54 UTC+5:30, tohr...@gmail.com wrote:
>>>
>>> Hello,
>>>
>>> you can change period by changing dtbo files.
>>>
>>> 1 Generate dts file from original dtbo file
>>> dtc -I dtb -O dts -o /lib/firmware/bone_pwm_P8_13-00A0.dts /lib/firmware
>>> /bone_pwm_P8_13-00A0.dtbo
>>>
>>> 2 Change period
>>> open file "/lib/firmware/bone_pwm_P8_13-00A0.dts" with editor at 
>>> lines around line 26:
>>> pwm_test_P8_13 {
>>> compatible = "pwm_test";
>>> pwms = <0xdeadbeef 0x1 0x7a120 0x1>;
>>>
>>>  and change to following, for example change period to 10ns=0.1ms
>>>
>>> pwm_test_P8_13 {
>>> compatible = "pwm_test";
>>> pwms = <0xdeadbeef 0x1 10 0x1>;
>>>   
>>> where
>>> -3rd parameter of line"pwms = ~" is period.
>>> -period (and other parameters) can be written in either decimal or 
>>> hexadecimal of 0xABC format.
>>> -default period 0x7a120 is 500 in decimal.
>>> -As you mentioned, Both A and B output for one eHRPWM must have same 
>>> period setting.
>>>  If not, the second device will fail to setup at "echo (device)> 
>>> /sys/devices/bone_capemgr.*/slots" command.
>>>
>>> 3 Compile to new dtbo file
>>> dtc -O dtb -o bone_pwm_P8_13-00A0.dtbo -b 0 -@ bone_pwm_P8_13-00A0.dts
>>>
>>>  You'd better back up original dtbo file before overwriting it.
>>>
>>> 4 Use new dtbo file. 
>>> echo bone_pwm_P8_13 > /sys/devices/bone_capemgr.*/slots
>>>
>>>
>>>
>>> 2013年6月4日火曜日 16時33分00秒 UTC+9 sultanof.ilo...@gmail.com:

 Hey, 
 yes sure, duty must be (0 <= duty <= period). Otherwise you would try 
 to to set a pwm duty cycle of less than 0% or more than 100%. Returning an 
 error to the user is a proper way to handle this. 

 As mentioned above EHRPWM1 and EHRPWM2 share the same base period (or 
 respectively the base frequency). If I enable both PWM ouputs, writing to 
 the period files always results in an error. Enabeling only one of the two 
 outputs lets me change the periods.
 This does make sense after all. I assume the necessary crosschecking of 
 the conditions (0 <= duty <= period) for related PWM outputs is simply not 
 implemented yet or mayby just faulty. 

 Am Montag, 3. Juni 2013 12:25:15 UTC+2 schrieb lawe...@gmail.com:
>
> Hi
>
> I'm just starting out, but here is what I found. Hopefully it can help 
> you.
> The period must be greater than duty.
> This worked fine for me:
> echo 10 > /sys/devices/ocp.2/pwm_test_P9_14.12/period
> Period is given in ns. Duty is given in ns on/off depending on 
> polarity.
>

>>>

-- 
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: Beaglebone Black won't power on, did I do something wrong? :(

[Benedek]

Hi,

I updated the Angstrom Distribution 2013-09-04 image on my BBB. The process 
seem to run well. After it ended, I get the SD card out from the BBB, and 
restarted it, with plugging in again the BBB via USB. But then only the 
power led lits, and nothing else. 
I've repeated the process many times, even with Debian 2014-05-04, but the 
result is the same.

Could anyone help me?

Thanks,
Ben


2013. április 30., kedd 14:19:57 UTC+2 időpontban Jason Stapels a 
következőt írta:
>
> Hi all,
>
> Just wanted to share my experience with my dead BBB. It's my first 
> experience with the Beagle line so it's possible I did something wrong 
> somewhere so I thought it would be a good idea to share my experiences in 
> case other newb's read this. Feel free to skip to the bottom for the 
> symptoms.
>
> -- Begin Background Info --
>
> I was lucky enough to get my BBB almost right away from Digikey. I 
> immediately installed the drivers on my Mac and started playing around with 
> it the first night. Unfortunately, the second night I couldn't get my Mac 
> to allocate an IP address through the USB to talk to it so I thought maybe 
> I shouldn't have skipped that "update software" step. So next I downloaded 
> the latest "flash eMMC" image, wrote it to an SD card and then went through 
> the upgrade process.
>
> Here's where things went a little South. After the first attempt the USR 
> lights eventually went solid (presumably indicating the flashing process 
> was finished) but when I rebooted it without the SD card, the power light 
> would come on but it wouldn't boot. After a couple repower attempts I 
> decided to flash it again. This time, at some point during the flash 
> process, the board seemed to just lose power (all the LEDs were off). 
> Attempts to power the board resulted in the same as before, power light 
> comes on but no booting.
>
> So, my assumption was I messed up the SD card image. I downloaded/reimaged 
> the SD card again, went through the flash process and this time it seemed 
> to finish. Now when I powered on the board it appeared to boot up. However, 
> I still couldn't get it to pick up an IP address from the Mac (after 
> reinstalling both drivers and a couple reboots). I read somewhere that 
> someone had a similar issue and an update to Angstrom solved it.
>
> This time I plugged the board into my linux box and I was able to access 
> the running linux image (yay!). I immediately SSH'd in, and went through 
> the Angstrom upgrade (opkg update; opkg upgrade). The upgrade took awhile 
> and seemed to have a few issues with the new kernel modules 
> (/lib/modules/blah didn't exist). I figured it was just a warning and after 
> the upgrade finished I unplugged the board and plugged it back into my 
> Mac...
>
> -- End Background Info --
>
> The power light came on... the USR lights all went solid for a couple 
> seconds... and then the board died. I can no longer seem to power the board 
> up at all. I've tried multiple USB cables, multiple USB ports on multiple 
> machines, and even tried the DC jack with a 5v/2.2A supply. :( I submitted 
> an RMA (although my board doesn't seem to have a serial number) because I 
> don't think I did anything wrong, but I'm a very sad panda regardless.
>
> Any ideas? Anything I should check?
>
> ~ Jason
>

-- 
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] SD card issue with beaglebone black

[Robert Nelson]

On Tue, Sep 16, 2014 at 10:22 AM, sanjay ahuja
 wrote:
> Hi,
>
> I tried using microSD card as extra storage for my beaglebone black. I
> followed the steps as mentioned at
> http://elinux.org/Beagleboard:MicroSD_As_Extra_Storage.
>
> I was able to use mount microSD card successfully. However I am facing some
> strange issue.
>
> when I do ls -lart on the mounted drive the permissions are
>
> drwx--  5 root root 16384 Jan  1  1970 drive
>
>
> If I try chmod o+rx,g+rx /media/drive, to change the permissions, it does
> not work. No error on issuing chmod command but permission does not get
> change.
>
> Infact I am not even able to change the user permission for any executable
> file under directory 'drive'.
>
> For ex.
> bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
> -rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/java
>
> bash-4.2# chmod u+x /media/drive/jdk1.7.0_60/bin/java
>
> bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
> -rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/java
>
> Since 'x' permission is missing, I am not able to execute any binary file. I
> am logged in as root user only. The jdk directory is expanded from jdk
> installer zip using command
> tar -xvf Downloads/jdk-7u60-linux-arm-vfp-sflt --owner root --group root
> --no-same-owner.
>
> No issues are encountered if the jdk directory is expanded under home
> directory instead of SD card.
>
> The partition details for SD Card:
>
> Usage : Filesystem
> Partition type: W95 FAT16 (LBA) (0x0e)
> Type: FAT (16-bit version)
> Device: /device/mmcblk1p1
> Mount Point: Mounted at /media/drive

re-partition it as "ext4"... fat16 doesnt' support user permissions..

Regards,

-- 
Robert Nelson
http://www.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] Building kernel 3.14.17-ti-r19

[Robert Nelson]

On Tue, Sep 16, 2014 at 10:07 AM, Robert Nelson  wrote:
> On Mon, Sep 15, 2014 at 4:03 PM, Charles Steinkuehler
>  wrote:
>> On 9/15/2014 3:59 PM, Robert Nelson wrote:
>>> On Mon, Sep 15, 2014 at 3:54 PM, Charles Steinkuehler
>>>  wrote:

 I'm apparently missing some sort of secret sauce (a.k.a. "clues").  :-/
>>>
>>> "deb_pkg" still hasn't learned to autodetect "armhf", so we do some
>>> deb voodoo around that.. ;)
>>>
>>> otherwise, the ti-r19 comes from LOCALVERSION
>>>
>>> So:
>>>
>>> make ARCH=arm KBUILD_DEBARCH=armhf LOCALVERSION=-ti-r19
>>> CROSS_COMPILE=${CC} KDEB_PKGVERSION=1wheezy deb-pkg
>>>
>>> will generate:
>>> linux-image-3.14.17-ti-r19_1wheezy_armhf.deb
>>
>>
>> Many thanks!
>>
>> I figured the missing LOCALVERSION was just something I didn't have vs.
>> the official build scripts, but when I got armel packages instead of
>> armhf I figured something was very wrong so I headed down a different path.
>
> Hey Charles,
>
> Ran into a problem last night with the pinmux, what's the proper way
> to grab a pin.  For the lcd4, i need P9_27_gpio_pd_pin
>
> diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> index 2df34ce..6f3dceb 100644
> --- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> @@ -15,7 +15,7 @@
> status = "okay";
> compatible = "ti,tilcdc,panel";
> pinctrl-names = "default";
> -   pinctrl-0 = <&bbcape_lcd_pins &bbcape_lcd4_disen_pins>;
> +   pinctrl-0 = <&bbcape_lcd_pins &P9_27_gpio_pd_pin>;
> panel-info {
> ac-bias   = <255>;
> ac-bias-intrpt= <0>;
>
> but, P9_27_pinmux still grabs it:
>
> [3.197699] pinctrl-single 44e10800.pinmux: pin 44e109a4.0 already
> requested by P9_27_pinmux.32; cannot claim for panel.48
> [3.209481] pinctrl-single 44e10800.pinmux: pin-105 (panel.48) status -22
> [3.21] pinctrl-single 44e10800.pinmux: could not request pin
> 105 (44e109a4.0) from group pinmux_P9_27_gpio_pd_pin  on device
> pinctrl-single
>
> ps, i disabled my git mirror script, so:
>
> https://github.com/RobertCNelson/ti-linux-kernel-dev
>
> is safe today, i'm going to try and only update my ti mirror when i
> already have my patchset rebased.

NM, found a work around..

When we "know" what cape is installed, thus we are already building a
*.dtb for it, just disable the pinmux, as it's already tied to the
cape.

diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
index 2df34ce..138a619 100644
--- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
@@ -6,6 +6,12 @@
  * published by the Free Software Foundation.
  */

+&ocp {
+   P9_27_pinmux {
+   status = "disabled";
+   };
+};
+
 &lcdc {
status = "okay";
 };

Regards,

-- 
Robert Nelson
http://www.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] SD card issue with beaglebone black

[sanjay ahuja]

Hi,

I tried using microSD card as extra storage for my beaglebone black. I 
followed the steps as mentioned 
at http://elinux.org/Beagleboard:MicroSD_As_Extra_Storage.

I was able to use mount microSD card successfully. However I am facing some 
strange issue.

when I do ls -lart on the mounted drive the permissions are

drwx--  5 root root 16384 Jan  1  1970 drive


If I try chmod o+rx,g+rx /media/drive, to change the permissions, it does 
not work. No error on issuing chmod command but permission does not get 
change.

Infact I am not even able to change the user permission for any executable 
file under directory 'drive'.

For ex. 
bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
-rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/java

bash-4.2# chmod u+x /media/drive/jdk1.7.0_60/bin/java

bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
-rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/java

Since 'x' permission is missing, I am not able to execute any binary file. 
I am logged in as root user only. The jdk directory is expanded from jdk 
installer zip using command
tar -xvf Downloads/jdk-7u60-linux-arm-vfp-sflt --owner root --group root 
--no-same-owner.

No issues are encountered if the jdk directory is expanded under home 
directory instead of SD card.

The partition details for SD Card:

Usage : Filesystem
Partition type: W95 FAT16 (LBA) (0x0e)
Type: FAT (16-bit version)
Device: /device/mmcblk1p1
Mount Point: Mounted at /media/drive

Any help will be really appreciated.

Thanks,
Sanjay Ahuja 


-- 
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: Ubuntu 14 - poor performance

[Richard-tx]

Unles I flashed it wrong twice in a row. I can't see how I could have 
botched the job.

I think that the next step is to report this as a bug.  Something in the 
kernel itself is causing the issue.

Does anyone have a url for reporting bugs?

Richard

On Monday, September 15, 2014 5:23:16 PM UTC-5, William Hermans wrote:
>
> There is also the chance that you somehow botched something on the Ubuntu 
> install. This can also cause performance issues. Such as if you did not 
> completely delete the root file system from debian before installing Ubuntu 
> on the same media. . . . You might think this would not be a problem. but 
> it can be . . .
>
> On Mon, Sep 15, 2014 at 3:20 PM, William Hermans  > wrote:
>
>> Ok so take a look at the output of pstree there. Notice how the "init 
>> system" is all over the tree ? First you have init as pid 1. then way down 
>> the tree you have systemd, followed by several upstart processes. This is 
>> normal from what I can tell on my own PC based Ubuntu installs ( actually 
>> Lubuntu, the same thing with different window manager ). But I also think 
>> this helps Ubuntu perform noticeably slower compared to Debian.
>>
>> I notice a performance difference on PCs as well. Debian, being much 
>> lighter just does some things faster.
>>
>> However, you can always google "Ubuntu 14.04 performance tuning" and see 
>> what you turn up. With that said, is there a particular package that Ubuntu 
>> has that Debian does not ? Otherwise ditch Ubuntu and go back to Debian . . 
>> .
>>
>> On Mon, Sep 15, 2014 at 10:00 AM, Richard-tx > > wrote:
>>
>>> Here is pstree -A
>>>
>>>  pstree -A
>>> init-+-acpid
>>>  |-avahi-daemon---avahi-daemon
>>>  |-cron
>>>  |-dbus-daemon
>>>  |-dhclient
>>>  |-7*[getty]
>>>  |-rsyslogd---3*[{rsyslogd}]
>>>  |-sshd---bash
>>>  |-sshd-+-sshd---bash---tail
>>>  |  |-sshd---bash---su---ksh---pstree
>>>  |  `-sshd---ksh
>>>  |-systemd-udevd
>>>  |-udhcpd
>>>  |-upstart-file-br
>>>  |-upstart-socket-
>>>  `-upstart-udev-br
>>>
>>>
>>> and top
>>>
>>> # top
>>> top - 11:59:28 up 1 day,  8:37,  4 users,  load average: 0.01, 0.05, 0.05
>>> Tasks:  82 total,   1 running,  81 sleeping,   0 stopped,   0 zombie
>>> %Cpu(s):  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  
>>> 0.0 st
>>> KiB Mem:508500 total,   474208 used,34292 free,13664 buffers
>>> KiB Swap:  1048572 total,  832 used,  1047740 free.   409384 cached 
>>> Mem
>>>
>>>
>>>
>>>
>>> On Monday, September 15, 2014 2:50:57 AM UTC-5, William Hermans wrote:

 Show us the output of pstree
 .

 On Mon, Sep 15, 2014 at 12:38 AM, Richard-tx  
 wrote:

> Here is the output from vmstat 2  
>
> You can see where I start the build.
>
> # vmstat 2
> procs ---memory-- ---swap-- -io -system-- 
> --cpu-
>  r  b   swpd   free   buff  cache   si   sobibo   in   cs us 
> sy id wa st
>  1  0832  12476  14188 42766800 538   83   61 10  
> 1 88  1  0
>  0  0832  12420  14188 42766800 0 0   21   47  0  
> 0 100  0  0
>  0  0832  12452  14188 42766800 0 0   23   45  0  
> 1 100  0  0
>  0  0832  12452  14196 42766400 0 6   27   54  0  
> 0 100  0  0
>  0  0832  12452  14196 42766800 0 0   21   50  0  
> 0 100  0  0
>  0  0832  12296  14196 42766800 0 2   23   47  0  
> 0 100  0  0
>  0  0832  12328  14196 42766800 0 0   26   45  0  
> 0 100  0  0
>  0  0832  12328  14200 42766400 0 4   31   54  0  
> 0 100  0  0
>  0  0832  12296  14200 42766800 0 0   24   44  0  
> 0 100  0  0
>  0  0832  12320  14200 42766800 0 0   35   70  0  
> 0 100  0  0
>  1  0832   4308  14200 42678800 0   684  560  399 69 
> 13 19  0  0
>  0  0832  13136  14200 42565600 0   128  201   94 25  
> 2 73  0  0
>  0  1832   9392  14204 42541200 0   102  261  258 34  
> 6 34 26  0
>  1  0832   9020  14208 42552800 0   154  568  272 91  
> 9  0  1  0
>  1  0832   7160  14208 42558800 092  448  278 70  
> 8 22  0  0
>  1  0832  13300  14216 42566000 0   240  597  490 84 
> 15  0  1  0
>  1  0832  12152  14216 42570400 0   130  635  513 87 
> 13  0  0  0
>  2  0832  10540  14224 42575600 0   172  580  407 87 
> 13  0  1  0
>  1  0832   8308  14224 42587600 0   140  585  431 91  
> 9  0  0  0
>  2  0832  10540  14224 42592400 0   198  572  329 89 
> 11  0  0  0
>  1  0832   9300  14232 42601600 0   172  584  436 88 
> 11  

Re: [beagleboard] Building kernel 3.14.17-ti-r19

[Robert Nelson]

On Mon, Sep 15, 2014 at 4:03 PM, Charles Steinkuehler
 wrote:
> On 9/15/2014 3:59 PM, Robert Nelson wrote:
>> On Mon, Sep 15, 2014 at 3:54 PM, Charles Steinkuehler
>>  wrote:
>>>
>>> I'm apparently missing some sort of secret sauce (a.k.a. "clues").  :-/
>>
>> "deb_pkg" still hasn't learned to autodetect "armhf", so we do some
>> deb voodoo around that.. ;)
>>
>> otherwise, the ti-r19 comes from LOCALVERSION
>>
>> So:
>>
>> make ARCH=arm KBUILD_DEBARCH=armhf LOCALVERSION=-ti-r19
>> CROSS_COMPILE=${CC} KDEB_PKGVERSION=1wheezy deb-pkg
>>
>> will generate:
>> linux-image-3.14.17-ti-r19_1wheezy_armhf.deb
>
>
> Many thanks!
>
> I figured the missing LOCALVERSION was just something I didn't have vs.
> the official build scripts, but when I got armel packages instead of
> armhf I figured something was very wrong so I headed down a different path.

Hey Charles,

Ran into a problem last night with the pinmux, what's the proper way
to grab a pin.  For the lcd4, i need P9_27_gpio_pd_pin

diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
index 2df34ce..6f3dceb 100644
--- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
@@ -15,7 +15,7 @@
status = "okay";
compatible = "ti,tilcdc,panel";
pinctrl-names = "default";
-   pinctrl-0 = <&bbcape_lcd_pins &bbcape_lcd4_disen_pins>;
+   pinctrl-0 = <&bbcape_lcd_pins &P9_27_gpio_pd_pin>;
panel-info {
ac-bias   = <255>;
ac-bias-intrpt= <0>;

but, P9_27_pinmux still grabs it:

[3.197699] pinctrl-single 44e10800.pinmux: pin 44e109a4.0 already
requested by P9_27_pinmux.32; cannot claim for panel.48
[3.209481] pinctrl-single 44e10800.pinmux: pin-105 (panel.48) status -22
[3.21] pinctrl-single 44e10800.pinmux: could not request pin
105 (44e109a4.0) from group pinmux_P9_27_gpio_pd_pin  on device
pinctrl-single

ps, i disabled my git mirror script, so:

https://github.com/RobertCNelson/ti-linux-kernel-dev

is safe today, i'm going to try and only update my ti mirror when i
already have my patchset rebased.

Regards,

-- 
Robert Nelson
http://www.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] BBB & MultiCast

[Micka]

I've tried to deactivate the Multicast with :

ifconfig eth0 -multicast

But when i check with this command, I can still see :

ip maddr show

2:  eth0
link  33:33:00:00:00:01
link  01:00:5e:00:00:01
link  33:33:ff:9a:05:07
*inet  224.0.0.1*
inet6 ff02::1:ff9a:507
inet6 ff02::1


Which is not good for me !


i've tried :

debian@beaglebone:/Distrib/Scripts$ sudo ip -r maddr delete 224.0.0.1 dev
eth0

ioctl: No such file or directory


I also tried to ping 224.0.0.1 from an another device .

And with the command tcpdump I can see that I'm receiving multicast packet :

debian@beaglebone:/Distrib/Scripts$ sudo tcpdump -p -i eth0 host 224.0.0.1
-n

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:09:28.679257 IP *190.190.167.1 > 224.0.0.1*: ICMP echo request, id 1,
seq 1913, length 40





Why ? I really don't know what to do about it, My idea is to deactivate
multicast in the kernel build config . Does it sounds good for you ?



Thank you,


Micka.

-- 
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] Impossible to desactivate Multicast

[Micka]

I've tried

-- 
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] Custom Audio cape with TLV320AIC3107 codec.

[Jesse Cobra]

What happens when you try the CircuitCO audio cape?
Does it work fine?

On Mon, Sep 15, 2014 at 10:14 PM, Prakash Parmar  wrote:

> Hi,
>
> How I can check this two things ?
>
> 2) check if SYS_RESET is actually deasserted and high
> 3) check if DIN/DOUT are correctly connected and not flipped, because DIN
> data must go into CODEC, while DOUT must go out and vise versa
>
> I'm not clear about this. Actually I have two Boards one with 10K
> resistors and one with 4.6K .
>
> Thanks & Regards,
> Prakash P.
>
> On Tue, Sep 16, 2014 at 12:34 AM, Maxim Podbereznyy 
> wrote:
>
>> what is exactly not clear for you?
>>
>> how to change resistors or how to copy/paste commands in a shell?
>>
>> 2014-09-15 21:46 GMT+04:00 :
>>
>>> HI,
>>> Thanks For reply.
>>>
>>> Can you please tell me how I can Do that ?
>>>
>>>
>>> Thanks & Regards,
>>> Prakash P.
>>>
>>> On Monday, September 15, 2014 8:01:19 PM UTC+5:30, liyaoshi wrote:

 Have you config the i2c pin pulled up ?
 and
 whats the speed of your i2c bus ?

 2014-09-15 2:09 GMT+08:00 :

> Hi,
>
> I have made custom Audio cape using TLV320AIC3107. Here is a circuit
> diagram :
>
>
> 
>
>
> I make it same  ( Pin configurations and all ) as what is available at
> CircuitCO using TLC320AIC3104 codec. I follow All steps like Disable HDMI
> and Load Device Tree BB-BONE-AUDI-02-00A0.dts  and I it works fine.
>
> But my problem is when I run speaker-test system hangs (freezes) and I
> have to Hard Reset BeagleBone.
>
> Here is what i did and what I get in dmesg.
>
>
> *root@beaglebone:~# speaker-test *
>
> speaker-test 1.0.25
>
> Playback device is default
> Stream parameters are 48000Hz, S16_LE, 1 channels
> Using 16 octaves of pink noise
> Rate set to 48000Hz (requested 48000Hz)
> Buffer size range from 128 to 32768
> Period size range from 8 to 2048
> Using max buffer size 32768
> Periods = 4
>
>
> *And in Dmesg : *
>
> [  205.540653] omap_i2c 4819c000.i2c: Arbitration lost
> [  206.572921] omap_i2c 4819c000.i2c: controller timed out
> [  206.580024] omap_i2c 4819c000.i2c: Arbitration lost
> [  207.611983] omap_i2c 4819c000.i2c: controller timed out
> [  207.618668] omap_i2c 4819c000.i2c: Arbitration lost
> [  212.626062] omap_i2c 4819c000.i2c: Arbitration lost
> [  213.658853] omap_i2c 4819c000.i2c: controller timed out
> [  213.666881] omap_i2c 4819c000.i2c: Arbitration lost
> [  214.699867] omap_i2c 4819c000.i2c: controller timed out
> [  214.707912] omap_i2c 4819c000.i2c: Arbitration lost
> [  215.740887] omap_i2c 4819c000.i2c: controller timed out
> [  215.748952] omap_i2c 4819c000.i2c: Arbitration lost
>
>
> I also cross check device tree file and I found that it also works
> for TLV320AIC3107 codec So I think it is not issue.
>
> An one have Idea what is wrong Please Help ME 
>
>
> Thanks & Regards
>
> Prakash P.
>
>  --
> 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.
>>>
>>
>>
>>
>> --
>> LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
>> Company - http://www.linkedin.com/company/mentorel
>> Facebook - https://www.facebook.com/mentorel.company
>>
>> --
>> 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/0ickf2E6NNs/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

Re: [beagleboard] Re: Beaglebone Black Rebooting Several Times Every Day

[Greg Kelley]

I just changed over to the Switching Power Supply and eth0 failed to come 
up on boot. I hit the reset button and a reboot brought it up. So now it 
seems there are eth0 issues as well as resets. Going from bad to worse.

-- 
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 Rebooting Several Times Every Day

[Greg Kelley]

One other note, current Debian distro that comes with BBB has ntpdate 
installed. I have removed ntpdate and installed ntp in it's place.

-- 
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 Rebooting Several Times Every Day

[Greg Kelley]

Update: I changed power supplies back to the 5v2a and removed wicd 
yesterday at 3:20pm. Ran fine until 8:42am and reset after 16hrs. This 
time, it didn't bring up eth0 and was unreachable. I pulled the power and 
powered back up, booted normally. Interesting thing is that syslog only 
shows the second boot on power up and not the reset reboot. Syslog was 
fresh at 6:25am and shows only one bootup sequence. Strange. I was hoping 
resets were from wicd, guess not. Problem still exists. I could deal with a 
single reset every day, but not when eth0 fails as my weather server 
uploads ftp files to my website every 15 minutes. I lost eth0 on reset back 
on 9/11 at 8:13am, so loss of eth0 is random in the resets. I have a 
Phihong Switching Power Supply 5v2a that I'm going to put on there and see 
if that helps, but unlikely since Thomas has lab quality power and all of 
his are resetting. Here's what's left in rc2.d, I have removed S06weewx for 
now (as well as apache2 and saned).

README  S01motd S03cron S03ssh   S05cups
S01boot_scripts.sh  S01rsyslog  S03dbus S03udhcpdS06rc.local
S01capemgr.sh   S01sudo S03loadcpufreq  S04avahi-daemon 
 S06rmnologin
S01hostapd  S01xrdp S03ntp  S04cpufrequtils
S01leds-off S03acpidS03rsyncS05bootlogs




-- 
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: prussdrv to remoteproc

[Kumar Abhishek]

Hi,

There isn't really a "hello world" for remoteproc as you would have to 
write a kernel module or modify the remoteproc kernel module to do anything 
concrete with the PRU remoteproc driver as of now. Plus if vrings do not 
really suit your application, then you will have to develop your own 
userspace layer to expose functionality to userspace. I've done it with a 
character device in BeagleLogic - the buffers can be read(), mmap()-ed, and 
poll()-ed, and there's some sysfs attributes and ioctl()'s for 
configuration. You might want to think of other possibilities depending 
upon your application.

The basic unit of communication between remoteproc and the PRU as of now is 
using *downcalls* and *syscalls*.

A *syscall *is when the PRU raises an IRQ and halts itself, storing some 
values in its registers. The kernel module handles the syscall IRQ, it 
reads the registers, manipulates them and resumes the PRU over the HALT 
instruction. See here 

 
for an example code of the syscall on the PRU side.

A *downcall *is initiated by the kernel module. Think of it as calling a 
function in the PRU from the kernel module and receiving the return value 
back in the kernel module.
*The PRU has to be polling for the downcall, and it acknowledges with a 
special syscall. Then the function handle_downcall is called, which 
receives the downcall value and the parameters. So the handle_downcall 
(example 
)
 
is a switch-case thing where the PRU does something and once it returns 
from this function, there is a syscall triggered which signals that the 
downcall is complete, the kernel module reads the return value of the 
function, after which the downcalling function in the kernel module returns 
with the return value.*

I can go on and make thjs post TL;DR but the crux is that remoteproc 
currently is very application-specific and you have to twist and adapt the 
kernel module to your needs. Once the remoteproc stuff gets finalized, 
ideally there would be a generic framework and userspace layer on top of 
the driver to allow you to write your own applications from userspace, in a 
similar way as it is currently done using libprussdrv.

I'm speaking all this from experience gained while developing BeagleLogic, 
and that was for the 3.8.13 kernel. With the BeagleBoard community now 
migrating to a 3.14 based kernel, BeagleLogic will have to be ported to 
3.14 which uses a new pru_rproc driver , and I will see how it can be done 
as there are differences between them, and some functionality will have to 
be added to the new driver.

Unfortunately I believe wading through thousands line of code would be the 
only option for now if you want to develop a new application.

On Tuesday, September 16, 2014 9:27:24 AM UTC+5:30, William Hermans wrote:
>
> And by examples, I mean an introductory "hello world" app. Not an already 
> working project with tens of thousands of lines of code to wade through.
>
> On Mon, Sep 15, 2014 at 8:51 PM, William Hermans  > wrote:
>
>> So where are the PRU examples of this ? To me this whole concept sounds 
>> very far fetched, but I will be the first to admit this would be a very 
>> very cool feature.
>>
>> On Mon, Sep 15, 2014 at 8:10 PM, Jason Kridner > > wrote:
>>
>>> On Sat, Sep 13, 2014 at 5:10 PM, Michael M >> > wrote:
>>> > I believe that PRUSpeak(https://github.com/deepakkarki/pruspeak/) 
>>> makes use
>>> > of remoteproc. I haven't made the transition yet, but I'm definitely 
>>> curious
>>> > about it. The complexity of implementing remoteproc seems much, much 
>>> greater
>>> > than using UIO or /dev/mem mapping. What is the benefit of using 
>>> remoteproc
>>> > over the other methods?
>>>
>>> I'm not sure of all the advantages, but here are some:
>>> * The more "Linux" way to do it with the remote processor being
>>> abstracted as a processor and not just some random memory mapped thing
>>> * Uses the kernel firmware loader making managing firmware something
>>> that can be easily coupled with the kernel and standard file formats
>>> * Processor-agnostic communication abstractions such that
>>> "platform-specific remoteproc drivers only need to provide a few
>>> low-level handlers, and then all rpmsg drivers will then just work"[1]
>>> * From a performance perspective, it enables handing of remote
>>> processor events from the kernel level which avoids a userspace
>>> context switch
>>> * Vring communication can be rather efficient as seen in the case of 
>>> BeagleLogic
>>>
>>> [1] 
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/remoteproc.txt
>>>
>>> >
>>> >
>>> > On Friday, September 12, 2014 5:57:17 AM UTC-7, Cedric Malitte wrote:
>>> >>
>>> >>
>>> >>
>>> >> Le vendredi 12 septembre 2014 04:11:18 UTC-4, Jon E a écrit :
>>> >>>
>>> >

[beagleboard] Re: Adafruit serial UART library seems to have wrong tty names

[cl]

Michel Lavoie  wrote:
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 81 lines --]
> 
> I strongly recommend that you read Adafruit's guide regarding the BBB's 
> device tree overlay. It really help me put this all together: 
> https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview
> 
> You will find there why and how to modify your uEnv.txt file in order to 
> enable ttyO1. In mine, the last line looks like this:
> 
> ...
> optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0
> 
> optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0
> 
> optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0
> 
> optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0
> 
> 
The Adafruit UART IO documentation specifically says that it *does*
export the overlays:-

The Adafruit IO Python library will export the UART device tree
overlays as a convenience. There are five serial ports brought to
the expansion headers (UART3 only has a single direction, TX), and
one (UART0) with dedicated headers that aren't available to use in
your Python programs.

... but not all the UARTs work.

In addition the use of the letter O in the device name is just silly! :-)

The devices it creates are called /dev/ttyO1, /dev/ttyO2, etc. with
the letter O.  There's not a mention anywhere that it's a letter
rather than a digit and given the context it's second nature to assume
it's a zero.  Still I did spot that eventually.

-- 
Chris Green
·

-- 
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] Can I *prevent* BBB from booting from microSD?

[cl]

I have a rev A6 (I think) BBB with the 2Gb eMMC memory.  I installed a
microSd card with Ubuntu on it and it has been booting from that quite
happily for the past few months.

I now seem to have currupted the Ubuntu image on the microSD card such
that it no longer boots successfully.  If I remove the microSD then
the BBB boots OK from the eMMC into Angstrom.

Is there any way I can force the BBB to boot from eMMC even though
there's a microSD card plugged in?  I want to recover some files from
the microSD card and I'm away from home and don't have any other means
of reading the microSD.

I do also have a revC BBB here but I guess that isn't going to act any
differently from the older one.

-- 
Chris Green
·

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