Re: [beagleboard] Re: PRU Pin Mux

2014-06-21 Thread Brandon I
"You have 100% full control over anything the PRU can access."

This pru code seems to disproves this. The PRU cannot modify the 
configuration registers.


// enable ocp master.
LBCO r0, C4, 4, 4
CLR r0, r0, 4
SBCO r0, C4, 4, 4

// turn on gpio
mov r1, 0x4000
mov r0, 0x44E07194
SBBO b, a, 0, 4
// readback
LBBO b, a, 0, 4

// gpio off
mov b, 0x4000
mov a, 0x44E07190
SBBO b, a, 0, 4
// readback
LBBO b, a, 0, 4 



On Monday, May 19, 2014 2:36:51 PM UTC-7, Charles Steinkuehler wrote:
>
> On 5/19/2014 4:06 PM, Brandon I wrote: 
> > The pin mux registers require privileged memory access, which is why 
> > the kernel space is usually required.  The pru can write these!? 
>
> Of course.  The PRU is directly wired into the on-chip bus, and bypasses 
> all ARM side sanity checks like memory page access restrictions.  You 
> have 100% full control over anything the PRU can access, which is just 
> about every significant chunk of hardware on the die except for: 
>
> * SGX-530 GPU 
> * AES & SHA crypto accelerator 
> * USB 
> * MMC 
>
> Details are in the Interconnects section of the TRM (section 10), and 
> remember: 
>
>   With great power comes great responsibility! 
>
> -- 
> Charles Steinkuehler 
> cha...@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: PRU Pin Mux

2014-06-21 Thread Brandon I
I apologize, a miss click posted that...full code below.


> *// enable ocp master.*LBCO r0, C4, 4, 4
> CLR r0, r0, 4
> SBCO r0, C4, 4, 4
> *// try to set gpio address*
>
> *// gpio on*mov r1, 0x4000# gpio 0, bit 14, p9.29
> mov r0, 0x44E07194  # gpio 0 set register
> SBBO r1, r0, 0, 4
> *// led on p9.26 light up here, devmem2 shows this address was set*
>
> *// readback*LBBO r1, r0, 0, 4
> *// readback matches!*
>
> *// gpio off*mov r1, 0x4000  # bit 14, p9.29
> mov r0, 0x44E07190  # gpio 0 clear register
> SBBO r1, r0, 0, 4
> *// led on p9.26 shuts off here, devmem2 shows this address was set*
> LBBO r1, r0, 0, 4 
> *// readback matches*
>
>
> *// try to set config address, P8.40*mov r1, 0x25
> mov r0, 0x44E108B8  
>
> *// devmem 2 says 0x44E108B8 = 0x5 (what i have it set to in dts)*SBBO 
> r1, r0, 0, 4
> *// devmem 2 says 0x44E108B8 is still 0x5!*
> LBBO r1, r0, 0, 4 
> *// readback doesn't match! r1 is now 0x5!*



You had me excited, even though I'd tested this before, and have read in 
multiple places that it's not possible.  :(

--Brandon


On Saturday, June 21, 2014 1:24:32 AM UTC-7, Brandon I wrote:
>
> "You have 100% full control over anything the PRU can access."
>
> This pru code seems to disproves this. The PRU cannot modify the 
> configuration registers.
>
>
> // enable ocp master.
> LBCO r0, C4, 4, 4
> CLR r0, r0, 4
> SBCO r0, C4, 4, 4
>
> // turn on gpio
> mov r1, 0x4000
> mov r0, 0x44E07194
> SBBO b, a, 0, 4
> // readback
> LBBO b, a, 0, 4
>
> // gpio off
> mov b, 0x4000
> mov a, 0x44E07190
> SBBO b, a, 0, 4
> // readback
> LBBO b, a, 0, 4 
>
>
>
> On Monday, May 19, 2014 2:36:51 PM UTC-7, Charles Steinkuehler wrote:
>>
>> On 5/19/2014 4:06 PM, Brandon I wrote: 
>> > The pin mux registers require privileged memory access, which is why 
>> > the kernel space is usually required.  The pru can write these!? 
>>
>> Of course.  The PRU is directly wired into the on-chip bus, and bypasses 
>> all ARM side sanity checks like memory page access restrictions.  You 
>> have 100% full control over anything the PRU can access, which is just 
>> about every significant chunk of hardware on the die except for: 
>>
>> * SGX-530 GPU 
>> * AES & SHA crypto accelerator 
>> * USB 
>> * MMC 
>>
>> Details are in the Interconnects section of the TRM (section 10), and 
>> remember: 
>>
>>   With great power comes great responsibility! 
>>
>> -- 
>> Charles Steinkuehler 
>> cha...@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] Setting volume from C++ on the audio cape (Rev B1)

2014-06-21 Thread John Syn

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

> I have the following code which I think should set the volume on the audio
> cape to 100%
Use alsamixer to experiment with the various settings. After that, it will
be easier to work out how to do this programatically.

Regards,
John
> 
> int32_t mixer_fd=0;
> 
> 
> mixer_fd=open("/dev/mixer", O_WRONLY);
> 
> if (mixer_fd>0)
> 
> 
> {
> 
> 
> int vol=0x6464;
> 
> 
> if
> (ioctl(mixer_fd, SOUND_MIXER_WRITE_VOLUME, &vol)==-1)
> 
> 
>{
> 
> 
>   std::cout <<"Error setting volume"< 
>}
> 
>close(mixer_fd);
> 
> 
> }
> 
> 
> 
> However, the volume is still barely audible.  Is there something else that
> needs to be done?
> -- 
> 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] Setting volume from C++ on the audio cape (Rev B1)

2014-06-21 Thread Charles Kerr
I found the answer, for those trying to do this.

Change this line
ioctl(mixer_fd, SOUND_MIXER_WRITE_VOLUME, &vol)

to

ioctl(mixer_fd, SOUND_MIXER_WRITE_PCM, &vol)


On Sat, Jun 21, 2014 at 4:48 AM, John Syn  wrote:

>
> From: Charles Kerr 
> Reply-To: "beagleboard@googlegroups.com" 
> Date: Friday, June 20, 2014 at 6:36 PM
> To: "beagleboard@googlegroups.com" 
> Subject: [beagleboard] Setting volume from C++ on the audio cape (Rev B1)
>
> I have the following code which I think should set the volume on the audio
> cape to 100%
>
> Use alsamixer to experiment with the various settings. After that, it will
> be easier to work out how to do this programatically.
>
> Regards,
> John
>
>
> int32_t mixer_fd=0;
>
> mixer_fd=open("/dev/mixer", O_WRONLY);
>
> if (mixer_fd>0)
>
> {
>
> int vol=0x6464;
>
> if (ioctl(
> mixer_fd, SOUND_MIXER_WRITE_VOLUME, &vol)==-1)
>
>{
>
>   std::cout <<"Error setting volume"<
>   }
>
>   close(mixer_fd);
>
> }
>
>
> However, the volume is still barely audible.  Is there something else that
> needs to be done?
>
> --
> 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/rTsdO11BIrY/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: BBB PRU input test

2014-06-21 Thread Manuel Berro Madero

Why 0b1?




On 06/21/2014 01:40 AM, TJF wrote:

Am Samstag, 21. Juni 2014 01:37:20 UTC+2 schrieb Manu:

I need to read the bit r31.t16 and capture the current state
either 1 or 0 and set it to r3

Try

   AND  r3, r31.b2, 0b1
--
For more options, visit http://beagleboard.org/discuss
---
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/PzuzGgfGvBU/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: BBB PRU input test

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

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


-- 
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: 8192.ko Module Format Error on Debian

2014-06-21 Thread Sibi Sankar

>
> It's awesome that you got it to work .I tried to do the same to rtl8192eu 
> and sadly the patch  by cmicali does not work. Is there any chance to get 
> it to work.Or should I ask cmicali for instructions on patching.Thank you.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You 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: PRU Pin Mux

2014-06-21 Thread TJF
A miss click and a miss post ...

The PRUSS can access the Control Modul pin mux registers.  It's working for 
a lot of libpruio users. Did you enable the OCP master port?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the 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] Fun with Chromium OS

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

https://chromium.googlesource.com/chromiumos/overlays/board-overlays.git/+/master/overlay-beaglebone/

https://chromium.googlesource.com/chromiumos/overlays/board-overlays.git/+/master/overlay-arm-generic/

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

2014-06-21 Thread Rafael Vega
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.


[beagleboard] Can't saveenv

2014-06-21 Thread Lucas Tanure
I can't saveenv. 

I got this:
U-Boot# saveenv
Saving Environment to NAND...
Erasing NAND...
Attempt to erase non block-aligned data

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To 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] Device Tree Overlay pinmux modification doe not modify the physical pin or the file interface values

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

Setting the Pin to an input w/ a pulldown:
-In my Device Tree Overlay file, I set GPIO pin P9_15(referred to as 48 by 
the kernel and having offset address 0x040) to be an input pin with a 
pulldown resistor(register value 0x27). 
-I echo the appropriate overlay to '/sys/devices/bone_capemgr.9/slots'
-When when I do a 'cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | 
grep '840' ' , I get 'pin 16 (44e10840) 0027 pinctrl-single'. This 
indicates that the pin is correctly set as an input and with a pulldown 
resistor. 
-When I do 'cat value' in the gpio48 directory, I get 1. I should get a 0 
since the pulldown is enabled.

Setting the pin to an output:
-In my Device Tree Overlay file, I set GPIO pin P9_15(referred to as 48 by 
the kernel and having offset address 0x040) to be an output pin (register 
value 0x07). 
-I echo the appropriate overlay to '/sys/devices/bone_capemgr.9/slots'
-When when I do a 'cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | 
grep '840' ' , I get 'pin 16 (44e10840) 0007 pinctrl-single'. This 
indicates that the pin is correctly set as an output. 
-When I do 'cat direction' in the gpio48 directory, I get 'in'. I should 
get 'out' since the pin is set as an output.

If I manually set the direction,value, etc... by echoing to the file 
interfaces, then everything works perfectly.

Should modifications in the DTO reflect in the file interfaces and on the 
physical pin itself, or is my understanding incorrect? Derek Molloy 
encounters this same issue in his GPIO video 
(https://www.youtube.com/watch?v=wui_wU1AeQc @31:00).

Thanks!
Michael

FYI, here is one of the DTOs:

/*  
* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Purpose License Version 2 as
* published by the Free Software Foundation
*
*/

/dts-v1/;
/plugin/;

/{
   compatible = "ti,beaglebone", "ti,beaglebone-black";
   part-number = "MM-LED-TEST";
   version = "00A0";

   fragment@0 {
 target = <&am33xx_pinmux>;
 __overlay__ {
pinctrl_LED: pinctrl_LED {
  pinctrl-single,pins = <

  0x040 0x27  /* P9_15(48): Input w/ pulldown resistor*/
 
>;
};
 };
   };

   fragment@1 {
  target = <&ocp>;
  __overlay__ {
  helper {
  compatible = "bone-pinmux-helper";
  pinctrl-names = "default";
  pinctrl-0 = <&pinctrl_LED>;
  status = "okay";
  };
  };
};
};

-- 
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't saveenv

2014-06-21 Thread David Lambert
I am not an expert in this, but if this is a Beaglebone, I don't think 
there is any NAND, so saveenv will not work. I think modifications to 
environment go in uEnv.txt or must be compiled into U-Boot.


HTH,

Dave.


On 06/21/2014 07:51 PM, Lucas Tanure wrote:

I can't saveenv.

I got this:
U-Boot# saveenv
Saving Environment to NAND...
Erasing NAND...
Attempt to erase non block-aligned data
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google 
Groups "BeagleBoard" group.
To 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: Device Tree Overlay pinmux modification doe not modify the physical pin or the file interface values

2014-06-21 Thread serge . nsk14


Hi Michael

 > When I do 'cat value' in the gpio48 directory, I get 1. I should get a 0 
since the pulldown is enabled.

> To my experience the 'cat value' not always reflects actual level on the 
wire.
and
> Should modifications in the DTO reflect in the file interfaces and on the 
physical pin itself,  
DTO modifications not always change the pinmux settings or pin state. (For 
example uEnv.txt settings might override them)

I concluded useless to study roots of every case, as well as got tired from 
checking pinmux settings and wire levels every time I connect new device to 
the system, and wrote small linux utility showing the punmux settings, GPIO 
configurations, and wire levels(if GPIO receiver enabled).
Maybe it will be helpful in your case, to understand what is where:  
www.academ.org/~sv/epc/pinmux.pdf

Serge



-- 
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] Watchdog timeout

2014-06-21 Thread ib saito
Hi all

I installed  Motion to BBB. And I was streaming video webcamera.
OS is Ubuntu 14.04.

When 320x240 settings of Motion, streaming has been successfully.
However, it failed when the 640x480 settings of Motion.

Then syslog
motion: [1] Resizing pre_capture buffer to 1 items
motion: [0] httpd Closing
motion: [0] httpd thread exit
motion: [0] Thread 1 - Watchdog timeout, trying to do a graceful restart
motion: [0] Thread 1 - Watchdog timeout, did NOT restart graceful, killing 
it!

I have also Beagleboard-xM, and I can stream 640x480 pixels on 
Beagleboard-xM.

I thought that the cause of the failure depend the ability of the BBB.
However, when tested using the mjpg_streamer, at 640x480 pixels, I was able 
to streaming.

What is cause of Whatchdog timeout?

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