Re: [beagleboard] PRU

[John Syne]

http://processors.wiki.ti.com/index.php/Mklib#Invoking_mklib_manually 


Regards,
John




> On Mar 23, 2016, at 5:55 PM, John Tobias  wrote:
> 
> Hi John,
> 
> I have the PRU Add on which is pru-icss-4.0.1. Then, I tried the latest 
> example from the git you provided.
> I have some compilation error (please see the attached log.txt)
> 
> Regards,
> 
> John
> 
> 
> On Wed, Mar 23, 2016 at 4:37 PM, John Syne  > wrote:
> Or you can use the latest examples from here:
> 
> https://git.ti.com/pru-software-support-package/pru-software-support-package 
> 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 23, 2016, at 1:54 PM, John Tobias > > wrote:
>> 
>> Hello Guys,
>> 
>> I am using debian image version 8.3 that I downloaded @ 
>> http://beagleboard.org/latest-images  
>> (4.1.15-ti-rt-r43). Also, I downloaded the TI SDK for AM335x 
>> (http://software-dl.ti.com/processor-sw/esd/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html
>>  
>> ).
>> 
>> I compiled the sample program for PRU (toggle_led.out) and copy it over in 
>> /lib/firmware/am335x-pru0-fw, but it did not work.
>> 
>> Then, I found Robert Nelson's binary and it works fine.
>> 
>> https://github.com/RobertCNelson/boot-scripts/commit/20a16f79be80886a1e030d197573b5950f98626d#diff-a0ab1dbc32ef29215c473f3b8979ad32
>>  
>> 
>> 
>> 
>> Any idea?.
>> 
>> Regards,
>> 
>> John
>> 
>> -- 
>> 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 
> .
> 

-- 
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 Internal ADC configuration settings?

[Audrey]

Thanks!

On Monday, March 21, 2016 at 4:06:10 PM UTC-4, RobertCNelson wrote:
>
> On Mon, Mar 21, 2016 at 2:52 PM, Audrey > 
> wrote: 
> > Thanks John, do you know where to get kernel 4.1? This is the only place 
> I 
> > know that has beaglebone images, but they don't specify which kernel 
> each 
> > version has: http://beagleboard.org/latest-images 
>
> Fresh as of yesterday: 4.1.18-ti-r53 
>
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
>  
>
> We've been fixing up the usb gadget setup, so they are a more stable 
> then the "8.3" images on http://beagleboard.org/latest-images 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

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

Re: [beagleboard] PRU

[John Tobias]

Hi John,

I have the PRU Add on which is pru-icss-4.0.1. Then, I tried the latest
example from the git you provided.
I have some compilation error (please see the attached log.txt)

Regards,

John


On Wed, Mar 23, 2016 at 4:37 PM, John Syne  wrote:

> Or you can use the latest examples from here:
>
>
> https://git.ti.com/pru-software-support-package/pru-software-support-package
>
> Regards,
> John
>
>
>
>
> On Mar 23, 2016, at 1:54 PM, John Tobias  wrote:
>
> Hello Guys,
>
> I am using debian image version 8.3 that I downloaded @
> http://beagleboard.org/latest-images (4.1.15-ti-rt-r43). Also, I
> downloaded the TI SDK for AM335x (
> http://software-dl.ti.com/processor-sw/esd/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html
> ).
>
> I compiled the sample program for PRU (toggle_led.out) and copy it over in
> /lib/firmware/am335x-pru0-fw, but it did not work.
>
> Then, I found Robert Nelson's binary and it works fine.
>
>
> https://github.com/RobertCNelson/boot-scripts/commit/20a16f79be80886a1e030d197573b5950f98626d#diff-a0ab1dbc32ef29215c473f3b8979ad32
>
>
> Any idea?.
>
> Regards,
>
> John
>
> --
> 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.
make[1]: Entering directory 
`/home/jtobias/ti/pru-software-support-package/examples'
make[2]: Entering directory 
`/home/jtobias/ti/pru-software-support-package/examples/am335x'
make[3]: Entering directory 
`/home/jtobias/ti/pru-software-support-package/examples/am335x/PRU_access_const_table'


Building project: PRU_access_const_table

Building file: PRU_access_const_table.c
Invoking: PRU Compiler
/home/jtobias/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/bin/clpru 
--include_path=/home/jtobias/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/include 
--include_path=../../../include --include_path=../../../include/am335x -v3 -O2 
--display_error_number --endian=little --hardware_mac=on --obj_directory=gen 
--pp_directory=gen -ppd -ppa -fe gen/PRU_access_const_table.object 
PRU_access_const_table.c

Building target: gen/PRU_access_const_table.out
Invoking: PRU Linker
/home/jtobias/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/bin/clpru -v3 -O2 
--display_error_number --endian=little --hardware_mac=on --obj_directory=gen 
--pp_directory=gen -ppd -ppa -z 
-i/home/jtobias/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/lib 
-i/home/jtobias/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/include --reread_libs 
--warn_sections --stack_size=0x100 --heap_size=0x100 -o 
gen/PRU_access_const_table.out gen/PRU_access_const_table.object 
-mgen/PRU_access_const_table.map ./AM335x_PRU.cmd --library=libc.a 
--library=../../../lib/rpmsg_lib.lib

Finished building target: gen/PRU_access_const_table.out

Output files can be found in the "gen" directory

Finished building project: PRU_access_const_table


make[3]: Leaving directory 
`/home/jtobias/ti/pru-software-support-package/examples/am335x/PRU_access_const_table'
make[3]: Entering directory 
`/home/jtobias/ti/pru-software-support-package/examples/am335x/PRU_ARMtoPRU_Interrupt'


Building project: PRU_ARMtoPRU_Interrupt

Building file: PRU_ARMtoPRU_Interrupt.c
Invoking: PRU Compiler
/home/jtobias/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/bin/clpru 
--include_path=/home/jtobias/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/include 
--include_path=../../../include --include_path=../../../include/am335x -v3 -O2 
--display_error_number --endian=little --hardware_mac=on --obj_directory=gen 
--pp_directory=gen -ppd -ppa -fe gen/PRU_ARMtoPRU_Interrupt.object 
PRU_ARMtoPRU_Interrupt.c

Building target: gen/PRU_ARMtoPRU_Interrupt.out
Invoking: PRU Linker
/home/jtobias/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/bin/clpru -v3 -O2 
--display_error_number --endian=little --hardware_mac=on --obj_directory=gen 
--pp_directory=gen -ppd -ppa -z 
-i/home/jtobias/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/lib 
-i/h

Re: [beagleboard] Re: Problem getting started with Beaglebone Black - USB working but not connecting

[Robert Nelson]

On Wed, Mar 23, 2016 at 7:06 PM, Nacho fq  wrote:

> PROBLEM SOLVED:
>
> Im so stupid! I've been fighting with this for weeks. *The problem was my
> "wired connections" were disabled.*
> Conclution: before doing anything, if anyone has this problem, check the
> "wired connections" are enabled.
>
> Thank you Robert for the answer.
>

Awesome, glad it works..

Lately, we have been also having what looked like issues with the 4.1.x
Real Time variant, so just in the last couple weeks switch back to the
v4.1.x non Real Time version..

Regards,

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

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

[beagleboard] Re: Problem getting started with Beaglebone Black - USB working but not connecting

[Nacho fq]

PROBLEM SOLVED:

Im so stupid! I've been fighting with this for weeks. *The problem was my 
"wired connections" were disabled.*
Conclution: before doing anything, if anyone has this problem, check the 
"wired connections" are enabled.

Thank you Robert for the answer.


El miércoles, 23 de marzo de 2016, 20:02:45 (UTC-3), Nacho fq escribió:
>
> Hi everyone!
>
> Im trying to ssh to BBB.
> I connect the BBB using the USB lead. I run the start.htm but step 1 does 
> not get highlighted. 
>
>
> 
>
>
> Im sure the problem comes from the Ubuntu distribution cause I have dual 
> boot and works fine on windows.
>
> Any Ideas? What could I try?
> I've read the problem might be related to known-hosts but I don't know 
> what to do with that information :P
>
> Thanks!
>

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

Re: [beagleboard] Re: Issue with USB devices through a USB hub

[Gerald Coley]

Yes, I saw that. I decided it was a secret message and sent it on just in
case.

Gerald


On Wed, Mar 23, 2016 at 4:20 PM,  wrote:

> Hi Karina,
>
> I agree with the posts on the power consumption.  Depending on the USB
> devices you are using you might be overloading the power.  I've experienced
> this when using SPI devices and USB devices in conjunction.  HP makes a
> very cheap 4 port USB hub with a 2A power supply that you can by through
> MicroCenter.com for about $5.  This fixed my problem.  You can probably
> pull datasheets on all your devices and add up the MAX mA draw.  I think
> the max output on the USB ports for BeagleBoard Black are around 600mA.
> Some USB devices like a WiFi and Bluetooth adapters in conjunction will
> consume most of this.  I noticed an issue when I actually tried to access
> my SPI device (another 2.4ghz radio) it would cause USB failure.  One last
> little thing of note.  Make sure you're brick that your USB is powering the
> BeagleBoard with is rated for at least 1A(2A is better for many devices).
> Hope this helps.
>
> Schuyler
>
> Note to the moderator - Sorry I tried to post this and sent it blank :)
>
> On Monday, March 21, 2016 at 10:49:32 PM UTC-6, Karina wrote:
>
>> Hi,
>>
>> I have a unpowered 2-port USB hub that I have connected to the BeagleBone
>> Black (Rev C). I have two (serial over ) USB devices connected to the two
>> port of the USB hub. They are are not powered to begin with. When i power
>> up the Beagle Bone, i see the USB hub listed in the output for 'lsusb'. Now
>> i power up the two USB device hanging off the USB hub. But i do not see the
>> USB devices listed in the output of 'lsusb'. Also, there is no /dev/ttyUSB*
>> file. For my project, it wold be ideal for the beagle bone to be powered up
>> before these USB devices. Any idea on what i have messed up or missed?
>>
>> I have verified that if i connect the USB device directly into the USB
>> port on the beagle bone black, then I can power the USB device after the
>> beagle bone is powered up and it shows up in the output of 'lsusb' and i
>> can control the device.
>>
>> Here are some more specifics about my setup.
>> 1. I am using the beagle bone black Rev C board.
>> 2. I am running Debian linux (jessie v 8.3) on the beagle bone black .
>> The version of the linux kernel is v3.8.15 -bone 71.
>> 3. I am powering the beagle bone with the power supply ( instead of over
>> the USB connector for etherent over USB).
>>
>> Thanks,
>> Karina
>>
>> --
> 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.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.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] Re: Issue with USB devices through a USB hub

[schuyler . ankele]

Hi Karina, 

I agree with the posts on the power consumption.  Depending on the USB 
devices you are using you might be overloading the power.  I've experienced 
this when using SPI devices and USB devices in conjunction.  HP makes a 
very cheap 4 port USB hub with a 2A power supply that you can by through 
MicroCenter.com for about $5.  This fixed my problem.  You can probably 
pull datasheets on all your devices and add up the MAX mA draw.  I think 
the max output on the USB ports for BeagleBoard Black are around 600mA. 
 Some USB devices like a WiFi and Bluetooth adapters in conjunction will 
consume most of this.  I noticed an issue when I actually tried to access 
my SPI device (another 2.4ghz radio) it would cause USB failure.  One last 
little thing of note.  Make sure you're brick that your USB is powering the 
BeagleBoard with is rated for at least 1A(2A is better for many devices). 
Hope this helps.

Schuyler

Note to the moderator - Sorry I tried to post this and sent it blank :)

On Monday, March 21, 2016 at 10:49:32 PM UTC-6, Karina wrote:
>
> Hi,
>
> I have a unpowered 2-port USB hub that I have connected to the BeagleBone 
> Black (Rev C). I have two (serial over ) USB devices connected to the two 
> port of the USB hub. They are are not powered to begin with. When i power 
> up the Beagle Bone, i see the USB hub listed in the output for 'lsusb'. Now 
> i power up the two USB device hanging off the USB hub. But i do not see the 
> USB devices listed in the output of 'lsusb'. Also, there is no /dev/ttyUSB* 
> file. For my project, it wold be ideal for the beagle bone to be powered up 
> before these USB devices. Any idea on what i have messed up or missed?
>
> I have verified that if i connect the USB device directly into the USB 
> port on the beagle bone black, then I can power the USB device after the 
> beagle bone is powered up and it shows up in the output of 'lsusb' and i 
> can control the device.
>
> Here are some more specifics about my setup.
> 1. I am using the beagle bone black Rev C board.
> 2. I am running Debian linux (jessie v 8.3) on the beagle bone black . The 
> version of the linux kernel is v3.8.15 -bone 71. 
> 3. I am powering the beagle bone with the power supply ( instead of over 
> the USB connector for etherent over USB).
>
> Thanks,
> Karina
>
>

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

[John Syne]

Or you can use the latest examples from here:

https://git.ti.com/pru-software-support-package/pru-software-support-package 


Regards,
John




> On Mar 23, 2016, at 1:54 PM, John Tobias  wrote:
> 
> Hello Guys,
> 
> I am using debian image version 8.3 that I downloaded @ 
> http://beagleboard.org/latest-images  
> (4.1.15-ti-rt-r43). Also, I downloaded the TI SDK for AM335x 
> (http://software-dl.ti.com/processor-sw/esd/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html
>  
> ).
> 
> I compiled the sample program for PRU (toggle_led.out) and copy it over in 
> /lib/firmware/am335x-pru0-fw, but it did not work.
> 
> Then, I found Robert Nelson's binary and it works fine.
> 
> https://github.com/RobertCNelson/boot-scripts/commit/20a16f79be80886a1e030d197573b5950f98626d#diff-a0ab1dbc32ef29215c473f3b8979ad32
>  
> 
> 
> 
> Any idea?.
> 
> Regards,
> 
> John
> 
> -- 
> 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] PRU

[John Syne]

Did you add this?

http://processors.wiki.ti.com/index.php/Processor_SDK_PRU-ICSS_Add_On_Package 


Regards,
John




> On Mar 23, 2016, at 1:54 PM, John Tobias  wrote:
> 
> Hello Guys,
> 
> I am using debian image version 8.3 that I downloaded @ 
> http://beagleboard.org/latest-images  
> (4.1.15-ti-rt-r43). Also, I downloaded the TI SDK for AM335x 
> (http://software-dl.ti.com/processor-sw/esd/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html
>  
> ).
> 
> I compiled the sample program for PRU (toggle_led.out) and copy it over in 
> /lib/firmware/am335x-pru0-fw, but it did not work.
> 
> Then, I found Robert Nelson's binary and it works fine.
> 
> https://github.com/RobertCNelson/boot-scripts/commit/20a16f79be80886a1e030d197573b5950f98626d#diff-a0ab1dbc32ef29215c473f3b8979ad32
>  
> 
> 
> 
> Any idea?.
> 
> Regards,
> 
> John
> 
> -- 
> 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] Problem getting started with Beaglebone Black - USB working but not connecting

[Nacho fq]

I flashed a new image a couple of months ago. 
The output of sudo ifconfig -a  command is:

enx6ceceb5dee7a Link encap:Ethernet  direcciónHW 6c:ec:eb:5d:ee:7a  
  ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST  MTU:1500  Métrica:1
  Paquetes RX:40 errores:0 perdidos:0 overruns:0 frame:0
  Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
  colisiones:0 long.colaTX:1000 
  Bytes RX:7518 (7.5 KB)  TX bytes:0 (0.0 B)

loLink encap:Bucle local  
  Direc. inet:127.0.0.1  Másc:255.0.0.0
  Dirección inet6: ::1/128 Alcance:Anfitrión
  ACTIVO BUCLE FUNCIONANDO  MTU:65536  Métrica:1
  Paquetes RX:1379 errores:0 perdidos:0 overruns:0 frame:0
  Paquetes TX:1379 errores:0 perdidos:0 overruns:0 carrier:0
  colisiones:0 long.colaTX:0 
  Bytes RX:130935 (130.9 KB)  TX bytes:130935 (130.9 KB)

wlp1s0Link encap:Ethernet  direcciónHW 34:23:87:45:b1:73  
  Direc. inet:192.168.1.6  Difus.:192.168.1.255  Másc:255.255.255.0
  Dirección inet6: fe80::3623:87ff:fe45:b173/64 Alcance:Enlace
  ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST  MTU:1500  Métrica:1
  Paquetes RX:40732 errores:0 perdidos:0 overruns:0 frame:0
  Paquetes TX:28400 errores:0 perdidos:0 overruns:0 carrier:0
  colisiones:0 long.colaTX:1000 
  Bytes RX:48689337 (48.6 MB)  TX bytes:4682653 (4.6 MB)



El miércoles, 23 de marzo de 2016, 20:09:12 (UTC-3), RobertCNelson escribió:
>
>
>
> On Wed, Mar 23, 2016 at 6:02 PM, Nacho fq > 
> wrote:
>
>> Hi everyone!
>>
>> Im trying to ssh to BBB.
>> I connect the BBB using the USB lead. I run the start.htm but step 1 does 
>> not get highlighted. 
>>
>>
>> 
>>
>>
>> Im sure the problem comes from the Ubuntu distribution cause I have dual 
>> boot and works fine on windows.
>>
>> Any Ideas? What could I try?
>> I've read the problem might be related to known-hosts but I don't know 
>> what to do with that information :P
>>
>
> Is this a factory out of box image? Or did you flash a new image?
>
> Since it worked on Windows, on linux what does:
>
> sudo ifconfig -a
>
> show? 
>
> Regards,
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

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

Re: [beagleboard] Problem getting started with Beaglebone Black - USB working but not connecting

[Robert Nelson]

On Wed, Mar 23, 2016 at 6:02 PM, Nacho fq  wrote:

> Hi everyone!
>
> Im trying to ssh to BBB.
> I connect the BBB using the USB lead. I run the start.htm but step 1 does
> not get highlighted.
>
>
> 
>
>
> Im sure the problem comes from the Ubuntu distribution cause I have dual
> boot and works fine on windows.
>
> Any Ideas? What could I try?
> I've read the problem might be related to known-hosts but I don't know
> what to do with that information :P
>

Is this a factory out of box image? Or did you flash a new image?

Since it worked on Windows, on linux what does:

sudo ifconfig -a

show?

Regards,

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

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

[beagleboard] Problem getting started with Beaglebone Black - USB working but not connecting

[Nacho fq]

Hi everyone!

Im trying to ssh to BBB.
I connect the BBB using the USB lead. I run the start.htm but step 1 does 
not get highlighted. 




Im sure the problem comes from the Ubuntu distribution cause I have dual 
boot and works fine on windows.

Any Ideas? What could I try?
I've read the problem might be related to known-hosts but I don't know what 
to do with that information :P

Thanks!

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

[beagleboard] PRU

[John Tobias]

Hello Guys,

I am using debian image version 8.3 that I downloaded @
http://beagleboard.org/latest-images (4.1.15-ti-rt-r43). Also, I downloaded
the TI SDK for AM335x (
http://software-dl.ti.com/processor-sw/esd/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html
).

I compiled the sample program for PRU (toggle_led.out) and copy it over in
/lib/firmware/am335x-pru0-fw, but it did not work.

Then, I found Robert Nelson's binary and it works fine.

https://github.com/RobertCNelson/boot-scripts/commit/20a16f79be80886a1e030d197573b5950f98626d#diff-a0ab1dbc32ef29215c473f3b8979ad32


Any idea?.

Regards,

John

-- 
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] u-boot can't find uEnv.txt

[David Hinkes]

Thank you for the clarification.  I also was not setting uenvboot in my
uEnv.txt.  This was causing some confusion on my part.  Now the board
attempts to load the kernel.

Now the board gets to the kernel and hangs after "Loading Kernel Image
...".  I'll report back when/if I get this sorted out.

On Fri, Mar 18, 2016 at 2:25 AM William Hermans  wrote:

> Just to make things perhaps a little clearer . . .
>
> william@beaglebone:~$ pwd
> /home/william
> william@beaglebone:~$ ls /
> ID.txt  boot  etc   lib media  nfs-uEnv.txt  proc  run   selinux
> sys  *uEnv.txt*   usr
> bin dev   home  lost+found  mntopt   root  sbin  srv
> tmp  uEnv.txt.save  var
>
>
> On Fri, Mar 18, 2016 at 2:11 AM, William Hermans 
> wrote:
>
>> Oh, and if you're using the eMMC only, you need to have uEnv,txt located
>> in the first partition at root of the "drive". So in laymen terms . . .
>>
>> /uEnv.txt - Not /boot/uEnv.txt or anywhere else *unless* you modify
>> uboots code before compiling.
>>
>> On Fri, Mar 18, 2016 at 2:08 AM, William Hermans 
>> wrote:
>>
>>> *It also seems that u-boot will try to took for uEnv.txt in several
 partitions, and seeing some "** Unable to read file uEnv.txt **" messages
 are ok.  Is this correct?*

>>>
>>> No. If you have an sdcard inserted at boot it will always load the first
>>> and second stage boot loaders from eMMC, but it will always look to the
>>> first partition on the sdcard for uEnv.txt.
>>>
>>> The only exception is if S2 is depressed at boot time, then the first
>>> and second stage boot loader will be "attempted" from the sdcard first, but
>>> uEnv.txt will still be expected to exist on the sdcard.
>>>
>>> Many people ( yours truly included ) have in the past bemoaned this
>>> behavior of uboot. When having a blank sdcard inserted at boot.
>>>
>>> On Thu, Mar 17, 2016 at 10:50 PM, David Hinkes 
>>> wrote:
>>>
 Thanks for the response, I appreciate it.


> > Questions:
> > (1) What are the requirements for the location of uEnv.txt?
>
> Look at the flow:
>
>
> http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;h=6ebe0b3866f9b137472cc080c9eb8f1e38233186;hb=df61a74e6845ec9bdcdd48d2aff5e9c2c6debeaa#l130
>
> /uEnv.txt in the first partition...
>

 I tried that and no luck.

 I realized that I configured u-boot with am335x_boneblack_defconfig and
 instead of am335x_evm_defconfig.

 It also seems that u-boot will try to took for uEnv.txt in several
 partitions, and seeing some "** Unable to read file uEnv.txt **" messages
 are ok.  Is this correct?

 --
 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/CYFyolL6Zm8/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] RPMsg from Linux User Space to PRU on Beaglebone Black

[John Syne]

Don’t include the .ko extension when using modprobe.

Regards,
John




> On Mar 23, 2016, at 9:32 AM, lucas  wrote:
> 
> Sorry forgot to copy the error message for the modprobe command: 
> 
> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# modprobe 
> virtio_rpmsg_bus.ko
> modprobe: FATAL: Module virtio_rpmsg_bus.ko not found.
> 
> On Wednesday, March 23, 2016 at 5:27:12 PM UTC+1, lucas wrote:
> Hi John, 
> 
> thank you very much for your answer. 
> 
> I am using the 4.1.15-ti-rt-r43 kernel. It's the kernel that came with the 
> debian image from the beaglebone website.  
> 
> Only the pruss_remoteproc module seems to be loaded on boot:
> 
> # lsmod
> Module  Size  Used by
> 8021q  17336  0
> garp5975  1 8021q
> mrp 7322  1 8021q
> stp 1911  1 garp
> llc 5257  2 stp,garp
> pruss_remoteproc   15296  2
> omap_rng4358  0
> rng_core7437  1 omap_rng
> usb_f_acm   7180  1
> u_serial   10596  3 usb_f_acm
> usb_f_rndis22734  1
> g_multi 5316  0
> usb_f_mass_storage 42745  2 g_multi
> u_ether12028  2 usb_f_rndis,g_multi
> libcomposite   43810  4 
> usb_f_acm,usb_f_rndis,g_multi,usb_f_mass_storage
> snd_soc_davinci_mcasp17266  0
> snd_soc_edma1150  1 snd_soc_davinci_mcasp
> spi_omap2_mcspi10681  0
> uio_pdrv_genirq 3521  0
> 
> Although the other modules do exist in the driver directory.
> 
> ls /lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg
> rpmsg_pru.ko  rpmsg-rpc.ko  virtio_rpmsg_bus.ko
> 
> I cannot modprob the modules:
> 
> # modprobe virtio_rpmsg_bus.ko
> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# modprobe 
> virtio_rpmsg_bus.ko
> 
> 
> But I can use insmod 
> 
> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# insmod 
> virtio_rpmsg_bus.ko
> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# lsmod
> Module  Size  Used by
> virtio_rpmsg_bus   13437  0
> 8021q  17336  0
> garp5975  1 8021q
> ...
> 
> 
> Should I try to switch to the kernel version you are using? Is there an image 
> or should I recompile the kernel? Any other ideas? 
> 
> Lucas
> 
> On Tuesday, March 22, 2016 at 7:40:56 PM UTC+1, john3909 wrote:
> Hi Lucas,
> 
> This seems to work just fine for me. What kernel version are you using?
> 
> I’m using V4.1.13-ti-r33. As you can see, all remoteproc/rpmsg kernel modules 
> are loaded automatically at boot time.
> 
> [   16.251480] pruss-rproc 4a30.pruss: 8 PRU interrupts parsed
> 
> [   16.251567] pruss-rproc 4a30.pruss: memorydram0: pa 0x4a30 
> size 0x2000 va e0ca 
> [   16.251595] pruss-rproc 4a30.pruss: memorydram1: pa 0x4a302000 
> size 0x2000 va e0ca4000 
> [   16.251621] pruss-rproc 4a30.pruss: memory shrdram2: pa 0x4a31 
> size 0x3000 va e0ca8000 
> [   16.251644] pruss-rproc 4a30.pruss: memory intc: pa 0x4a32 
> size 0x2000 va e0cac000 
> [   16.251672] pruss-rproc 4a30.pruss: memory  cfg: pa 0x4a326000 
> size 0x2000 va e0cb 
> [   16.252174] pruss-rproc 4a30.pruss: creating platform devices for PRU 
> cores
> [   16.374800] pru-rproc 4a334000.pru0: memory iram: pa 0x4a334000 size 
> 0x2000 va e0cb4000
> [   16.374858] pru-rproc 4a334000.pru0: memory  control: pa 0x4a322000 size 
> 0x400 va e0876000 
> [   16.374901] pru-rproc 4a334000.pru0: memorydebug: pa 0x4a322400 size 
> 0x100 va e0c9e400 
> [   16.375152]  remoteproc1: 4a334000.pru0 is available   
> 
> [   16.380153]  remoteproc1: Note: remoteproc is still under development and 
> considered experimental. 
> [   16.572902]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
> backward compatibility isn't yet guaranteed. 
> [   16.778752]  remoteproc1: registered virtio0 (type 7)  
> 
> [   16.811201] pru-rproc 4a334000.pru0: PRU rproc node 
> /ocp/pruss@4a30/pru@4a334000 probed successfully   
> [   16.932818] pru-rproc 4a338000.pru1: memory iram: pa 0x4a338000 size 
> 0x2000 va e0ccc000
> [   16.932891] pru-rproc 4a338000.pru1: memory  control: pa 0x4a324000 size 
> 0x400 va e0cd 
> [   16.932918] pru-rpr

Re: [beagleboard] SPI BBB Master, BBB Slave

[John Syne]

What exactly are you trying to do? Please explain your application so that we 
can propose a solution.

Regards,
John




> On Mar 23, 2016, at 4:29 AM, yaron.leder...@gmail.com wrote:
> 
> Hi,
> 
> Is there any resolution about this ? Since I'm having the same consideration
> 
> Thanks !
> 
> 
> On Wednesday, November 4, 2015 at 4:15:23 PM UTC+2, ravi...@gmail.com wrote:
> Hi,
> 
> I'm trying to setup SPI slave mode with same above method and changed 
> OMAP2_MCSPI_MODULCTRL_MS set to 0 for slave mode.
> 
> i'm facing issue in master mode and slave both on sckl pin configuration. 
> 
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV 
>  in this link why sckl pin 
> is configured as INPUT 0x33 but it will work with same configuration if i 
> change it to OUTPUT it doesn't work with any slave device and no clock on 
> that pin.
> 
> Please anyone clarify this doubt and issues.
> 
> For slave mode i tried to change OMAP2_MCSPI_MODULCTRL_MS bit in driver file 
> spi_omap2_mcspi.c but no use. still its master only. 
> 
> Please provide any suggestion or exact procedure.
> 
> Thank you in advance.
> 
> Regard s
> Ravi 
> 
> On Thursday, September 18, 2014 at 5:45:47 AM UTC+5:30, phil...@gmail.com <> 
> wrote:
> 
> I am having issues with SPI between two BBB that may be simple to solve. I 
> have spidev_test loopback working on each board but am having problems 
> connecting the two.
> 
> spi0 master dts:
>   0x150 0x10  /* spi0_sclk, OUTPUT_PULLUP | MODE0 */
>   0x154 0x30  /* spi0_d0, INPUT_PULLUP | MODE0 */
>   0x158 0x10  /* spi0_d1, OUTPUT_PULLUP | MODE0 */
>   0x15c 0x10  /* spi0_cs0, OUTPUT_PULLUP | MODE0 */
> 
> spi slave dts:
>   0x150 0x30  /* spi0_sclk, INPUT_PULLUP | MODE0 */
>   0x154 0x10  /* spi0_d0, OUTPUT_PULLUP | MODE0 */
>   0x158 0x30  /* spi0_d1, INPUT_PULLUP | MODE0 */
>   0x15c 0x30  /* spi0_cs0, INPUT_PULLUP | MODE0 */
> 
> 
> The oscilloscope shows activity when spi0_sckl (P9_17) is not connected but 
> nothing when P9_17 is connected between both boards. 
> I am sending bytes from master with the command: echo 1 > /dev/spidev1.0
> 
> I need 4-8mbit/sec transfer, is this achievable by bit banging over GPIO and 
> would that be a viable alternative to getting SPI working?
> 
> 
> -- 
> 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] BBB Jessie 8.3 boot default eMMC or sd card?

Thank you!

Vinicius

Em 23-03-2016 15:55, Robert Nelson escreveu:

On Wed, Mar 23, 2016 at 1:32 PM, S&DeMario  wrote:

Is it possible to disable boot via sd card, enabling them only by pressing
the boot button?

If affirmative, how to proceed?

The boot search order is controlled from here:

https://github.com/u-boot/u-boot/blob/v2016.03/include/configs/am335x_evm.h#L87-L93

mmc 0 = microSD
mmc 1 = eMMC

Regards,



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

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Jessie 8.3 boot default eMMC or sd card?

[Robert Nelson]

On Wed, Mar 23, 2016 at 1:32 PM, S&DeMario  wrote:
> Is it possible to disable boot via sd card, enabling them only by pressing
> the boot button?
>
> If affirmative, how to proceed?

The boot search order is controlled from here:

https://github.com/u-boot/u-boot/blob/v2016.03/include/configs/am335x_evm.h#L87-L93

mmc 0 = microSD
mmc 1 = eMMC

Regards,

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

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

Re: [beagleboard] BBB Jessie 8.3 boot default eMMC or sd card?

Is it possible to disable boot via sd card, enabling them only by 
pressing the boot button?


If affirmative, how to proceed?

thanks

Vinicius

Em 23-03-2016 13:34, Robert Nelson escreveu:

On Wed, Mar 23, 2016 at 11:28 AM, Joshua Datko  wrote:

Is the default boot the eMMC or the sd card?

the bootrom read's the eMMC first..


I thought it was the eMMC but I'm helping out some friends and they
took the latest Jessie 8.3 console flasher image, stuck in the sd
card, turned on the BBB, and it flashed without holding the user boot
button.

I'm not sure what they were running previously :(

As long as it was running a default image, either Angstrom/Debian
later then: 2013.06.20

Or any of my images from rcn-ee.com/elinux.org/etc..


I wouldn't have thought that would work and I don't have a spare BBB
at the moment to try it, so I was wondering if 1.) I'm confused or 2.)
something changed or 3.) someone can upgrade my knowledge of how the
BBB boots.

Nothing's really changed.  The old Angstrom image's required holding
the boot button..

We've kept the instructions the same, recommending users hold the boot
button, to help work around some issues on versions of u-boot from
2013/2014..

Otherwise, the 'flasher' images really don't require the boot button
pressed now-days..

Regards,



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

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Jessie 8.3 boot default eMMC or sd card?

[Joshua Datko]

On Wed, Mar 23, 2016 at 10:34 AM, Robert Nelson  wrote:

> We've kept the instructions the same, recommending users hold the boot
> button, to help work around some issues on versions of u-boot from
> 2013/2014..

Great thanks! I've been pushing that button for so long now... not
pushing it would feel like that scene from LOST ;)

-- 
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: Issue with USB devices through a USB hub

[schuyler . ankele]

Hi Karina,


On Monday, March 21, 2016 at 10:49:32 PM UTC-6, Karina wrote:
>
> Hi,
>
> I have a unpowered 2-port USB hub that I have connected to the BeagleBone 
> Black (Rev C). I have two (serial over ) USB devices connected to the two 
> port of the USB hub. They are are not powered to begin with. When i power 
> up the Beagle Bone, i see the USB hub listed in the output for 'lsusb'. Now 
> i power up the two USB device hanging off the USB hub. But i do not see the 
> USB devices listed in the output of 'lsusb'. Also, there is no /dev/ttyUSB* 
> file. For my project, it wold be ideal for the beagle bone to be powered up 
> before these USB devices. Any idea on what i have messed up or missed?
>
> I have verified that if i connect the USB device directly into the USB 
> port on the beagle bone black, then I can power the USB device after the 
> beagle bone is powered up and it shows up in the output of 'lsusb' and i 
> can control the device.
>
> Here are some more specifics about my setup.
> 1. I am using the beagle bone black Rev C board.
> 2. I am running Debian linux (jessie v 8.3) on the beagle bone black . The 
> version of the linux kernel is v3.8.15 -bone 71. 
> 3. I am powering the beagle bone with the power supply ( instead of over 
> the USB connector for etherent over USB).
>
> Thanks,
> Karina
>
>

-- 
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: GSoC Project: a realtime audio effects Box

[Valentin Le bescond]

Not yet! I still have to cleanup some specific stuff (you know... Ftp
passwords, stupid comments, etc... ) but I am planning to!

Le mer. 23 mars 2016 17:07, 'Johannes Wegener' via BeagleBoard <
beagleboard@googlegroups.com> a écrit :

>
>
> Am Montag, 21. März 2016 17:14:32 UTC+1 schrieb Oolav:
>>
>> "bachelor thesis about acoustic measurements". Cool, can I read it ?
>>
>
> Of course! But it is in german - so I don't know how much that might help
> you? https://johanneswegener.de/BA.pdf
>
>
>> I've built a sound level monitoring station with a raspberry pi and a
>> wolfson audio card (with added IEPE bias).
>> Then it's all the ALSA API for capture and Qt for the rest on the
>> software side (IIR Filters, Network stuff etc.).
>> I didn't implement playback though.
>>
>
>  intereseting - is the code on github or something?
>
> --
> 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/M__bEuvgvOA/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] BBB Jessie 8.3 boot default eMMC or sd card?

[Robert Nelson]

On Wed, Mar 23, 2016 at 11:28 AM, Joshua Datko  wrote:
> Is the default boot the eMMC or the sd card?

the bootrom read's the eMMC first..

> I thought it was the eMMC but I'm helping out some friends and they
> took the latest Jessie 8.3 console flasher image, stuck in the sd
> card, turned on the BBB, and it flashed without holding the user boot
> button.
>
> I'm not sure what they were running previously :(

As long as it was running a default image, either Angstrom/Debian
later then: 2013.06.20

Or any of my images from rcn-ee.com/elinux.org/etc..

> I wouldn't have thought that would work and I don't have a spare BBB
> at the moment to try it, so I was wondering if 1.) I'm confused or 2.)
> something changed or 3.) someone can upgrade my knowledge of how the
> BBB boots.

Nothing's really changed.  The old Angstrom image's required holding
the boot button..

We've kept the instructions the same, recommending users hold the boot
button, to help work around some issues on versions of u-boot from
2013/2014..

Otherwise, the 'flasher' images really don't require the boot button
pressed now-days..

Regards,

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

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

Re: [beagleboard] RPMsg from Linux User Space to PRU on Beaglebone Black

[lucas]

Sorry forgot to copy the error message for the modprobe command: 

root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# 
modprobe virtio_rpmsg_bus.ko
modprobe: FATAL: Module virtio_rpmsg_bus.ko not found.

On Wednesday, March 23, 2016 at 5:27:12 PM UTC+1, lucas wrote:
>
> Hi John, 
>
> thank you very much for your answer. 
>
> I am using the 4.1.15-ti-rt-r43 kernel. It's the kernel that came with the 
> debian image from the beaglebone website.  
>
> Only the pruss_remoteproc module seems to be loaded on boot:
>
> # lsmod
> Module  Size  Used by
> 8021q  17336  0
> garp5975  1 8021q
> mrp 7322  1 8021q
> stp 1911  1 garp
> llc 5257  2 stp,garp
> pruss_remoteproc   15296  2
> omap_rng4358  0
> rng_core7437  1 omap_rng
> usb_f_acm   7180  1
> u_serial   10596  3 usb_f_acm
> usb_f_rndis22734  1
> g_multi 5316  0
> usb_f_mass_storage 42745  2 g_multi
> u_ether12028  2 usb_f_rndis,g_multi
> libcomposite   43810  4 
> usb_f_acm,usb_f_rndis,g_multi,usb_f_mass_storage
> snd_soc_davinci_mcasp17266  0
> snd_soc_edma1150  1 snd_soc_davinci_mcasp
> spi_omap2_mcspi10681  0
> uio_pdrv_genirq 3521  0
>
> Although the other modules do exist in the driver directory.
>
> ls /lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg
> rpmsg_pru.ko  rpmsg-rpc.ko  virtio_rpmsg_bus.ko
>
> I cannot modprob the modules:
>
> # modprobe virtio_rpmsg_bus.ko
> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# 
> modprobe virtio_rpmsg_bus.ko
>
>
> But I can use insmod 
>
> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# insmod 
> virtio_rpmsg_bus.ko
> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# lsmod
> Module  Size  Used by
> virtio_rpmsg_bus   13437  0
> 8021q  17336  0
> garp5975  1 8021q
> ...
>
>
> Should I try to switch to the kernel version you are using? Is there an 
> image or should I recompile the kernel? Any other ideas? 
>
> Lucas
>
> On Tuesday, March 22, 2016 at 7:40:56 PM UTC+1, john3909 wrote:
>>
>> Hi Lucas,
>>
>> This seems to work just fine for me. What kernel version are you using?
>>
>> I’m using V4.1.13-ti-r33. As you can see, all remoteproc/rpmsg kernel 
>> modules are loaded automatically at boot time.
>>
>> [   16.251480] pruss-rproc 4a30.pruss: 8 PRU interrupts parsed   
>>  
>> [   16.251567] pruss-rproc 4a30.pruss: memorydram0: pa 0x4a30 
>> size 0x2000 va e0ca 
>> [   16.251595] pruss-rproc 4a30.pruss: memorydram1: pa 0x4a302000 
>> size 0x2000 va e0ca4000 
>> [   16.251621] pruss-rproc 4a30.pruss: memory shrdram2: pa 0x4a31 
>> size 0x3000 va e0ca8000 
>> [   16.251644] pruss-rproc 4a30.pruss: memory intc: pa 0x4a32 
>> size 0x2000 va e0cac000 
>> [   16.251672] pruss-rproc 4a30.pruss: memory  cfg: pa 0x4a326000 
>> size 0x2000 va e0cb 
>> [   16.252174] pruss-rproc 4a30.pruss: creating platform devices for 
>> PRU cores
>> [   16.374800] pru-rproc 4a334000.pru0: memory iram: pa 0x4a334000 
>> size 0x2000 va e0cb4000
>> [   16.374858] pru-rproc 4a334000.pru0: memory  control: pa 0x4a322000 
>> size 0x400 va e0876000 
>> [   16.374901] pru-rproc 4a334000.pru0: memorydebug: pa 0x4a322400 
>> size 0x100 va e0c9e400 
>> [   16.375152]  remoteproc1: 4a334000.pru0 is available   
>> 
>> [   16.380153]  remoteproc1: Note: remoteproc is still under development 
>> and considered experimental. 
>> [   16.572902]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
>> backward compatibility isn't yet guaranteed. 
>> [   16.778752]  remoteproc1: registered virtio0 (type 7) 
>>  
>> [   16.811201] pru-rproc 4a334000.pru0: PRU rproc node 
>> /ocp/pruss@4a30/pru@4a334000 probed successfully   
>> [   16.932818] pru-rproc 4a338000.pru1: memory iram: pa 0x4a338000 
>> size 0x2000 va e0ccc000
>> [   16.932891] pru-rproc 4a338000.pru1: memory  control: pa 0x4a324000 
>> size 0x400 va e0cd 
>> [   16.932918] pru-rproc 4a338000.pru1: memorydebug: pa 0x4a324400 
>> size 0x100 va e0cd2400  

[beagleboard] BBB Jessie 8.3 boot default eMMC or sd card?

[Joshua Datko]

Is the default boot the eMMC or the sd card?

I thought it was the eMMC but I'm helping out some friends and they
took the latest Jessie 8.3 console flasher image, stuck in the sd
card, turned on the BBB, and it flashed without holding the user boot
button.

I'm not sure what they were running previously :(

I wouldn't have thought that would work and I don't have a spare BBB
at the moment to try it, so I was wondering if 1.) I'm confused or 2.)
something changed or 3.) someone can upgrade my knowledge of how the
BBB boots.

Josh

-- 
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] RPMsg from Linux User Space to PRU on Beaglebone Black

[lucas]

Hi John, 

thank you very much for your answer. 

I am using the 4.1.15-ti-rt-r43 kernel. It's the kernel that came with the 
debian image from the beaglebone website.  

Only the pruss_remoteproc module seems to be loaded on boot:

# lsmod
Module  Size  Used by
8021q  17336  0
garp5975  1 8021q
mrp 7322  1 8021q
stp 1911  1 garp
llc 5257  2 stp,garp
pruss_remoteproc   15296  2
omap_rng4358  0
rng_core7437  1 omap_rng
usb_f_acm   7180  1
u_serial   10596  3 usb_f_acm
usb_f_rndis22734  1
g_multi 5316  0
usb_f_mass_storage 42745  2 g_multi
u_ether12028  2 usb_f_rndis,g_multi
libcomposite   43810  4 
usb_f_acm,usb_f_rndis,g_multi,usb_f_mass_storage
snd_soc_davinci_mcasp17266  0
snd_soc_edma1150  1 snd_soc_davinci_mcasp
spi_omap2_mcspi10681  0
uio_pdrv_genirq 3521  0

Although the other modules do exist in the driver directory.

ls /lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg
rpmsg_pru.ko  rpmsg-rpc.ko  virtio_rpmsg_bus.ko

I cannot modprob the modules:

# modprobe virtio_rpmsg_bus.ko
root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# 
modprobe virtio_rpmsg_bus.ko


But I can use insmod 

root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# insmod 
virtio_rpmsg_bus.ko
root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# lsmod
Module  Size  Used by
virtio_rpmsg_bus   13437  0
8021q  17336  0
garp5975  1 8021q
...


Should I try to switch to the kernel version you are using? Is there an 
image or should I recompile the kernel? Any other ideas? 

Lucas

On Tuesday, March 22, 2016 at 7:40:56 PM UTC+1, john3909 wrote:
>
> Hi Lucas,
>
> This seems to work just fine for me. What kernel version are you using?
>
> I’m using V4.1.13-ti-r33. As you can see, all remoteproc/rpmsg kernel 
> modules are loaded automatically at boot time.
>
> [   16.251480] pruss-rproc 4a30.pruss: 8 PRU interrupts parsed 
>
> [   16.251567] pruss-rproc 4a30.pruss: memorydram0: pa 0x4a30 
> size 0x2000 va e0ca 
> [   16.251595] pruss-rproc 4a30.pruss: memorydram1: pa 0x4a302000 
> size 0x2000 va e0ca4000 
> [   16.251621] pruss-rproc 4a30.pruss: memory shrdram2: pa 0x4a31 
> size 0x3000 va e0ca8000 
> [   16.251644] pruss-rproc 4a30.pruss: memory intc: pa 0x4a32 
> size 0x2000 va e0cac000 
> [   16.251672] pruss-rproc 4a30.pruss: memory  cfg: pa 0x4a326000 
> size 0x2000 va e0cb 
> [   16.252174] pruss-rproc 4a30.pruss: creating platform devices for 
> PRU cores
> [   16.374800] pru-rproc 4a334000.pru0: memory iram: pa 0x4a334000 
> size 0x2000 va e0cb4000
> [   16.374858] pru-rproc 4a334000.pru0: memory  control: pa 0x4a322000 
> size 0x400 va e0876000 
> [   16.374901] pru-rproc 4a334000.pru0: memorydebug: pa 0x4a322400 
> size 0x100 va e0c9e400 
> [   16.375152]  remoteproc1: 4a334000.pru0 is available   
> 
> [   16.380153]  remoteproc1: Note: remoteproc is still under development 
> and considered experimental. 
> [   16.572902]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
> backward compatibility isn't yet guaranteed. 
> [   16.778752]  remoteproc1: registered virtio0 (type 7)   
>
> [   16.811201] pru-rproc 4a334000.pru0: PRU rproc node 
> /ocp/pruss@4a30/pru@4a334000 probed successfully   
> [   16.932818] pru-rproc 4a338000.pru1: memory iram: pa 0x4a338000 
> size 0x2000 va e0ccc000
> [   16.932891] pru-rproc 4a338000.pru1: memory  control: pa 0x4a324000 
> size 0x400 va e0cd 
> [   16.932918] pru-rproc 4a338000.pru1: memorydebug: pa 0x4a324400 
> size 0x100 va e0cd2400 
> [   16.933190]  remoteproc2: 4a338000.pru1 is available   
> 
> [   16.938192]  remoteproc2: Note: remoteproc is still under development 
> and considered experimental. 
> [   17.081421]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and 
> backward compatibility isn't yet guaranteed. 
> [   17.114912]  remot

Re: [beagleboard] Re: GSoC Project: a realtime audio effects Box

['Johannes Wegener' via BeagleBoard]

Am Montag, 21. März 2016 17:14:32 UTC+1 schrieb Oolav:
>
> "bachelor thesis about acoustic measurements". Cool, can I read it ?
>

Of course! But it is in german - so I don't know how much that might help 
you? https://johanneswegener.de/BA.pdf
 

> I've built a sound level monitoring station with a raspberry pi and a 
> wolfson audio card (with added IEPE bias).
> Then it's all the ALSA API for capture and Qt for the rest on the software 
> side (IIR Filters, Network stuff etc.).
> I didn't implement playback though.
>

 intereseting - is the code on github or something?

-- 
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] __halt() call can`t be detected by prussdrv_pru_wait_event

[ardanza]

Hi,

I`m having troubles with pru c code. My BBG is running the Bone-Debian 7.9 
eMMC (2015-11-03-4gb) image, which Kernel Version "Linux 3.8.13-bone79 
armv7l" and my host machine is a Ubuntu 14.04 LTS 64 bits virtual machine 
with ti-processor-sdk-linux-am335x-evm-02.00.01.07 installed.

I follow this guide to start with the PRU 
development, 
http://www.michaelcantux.com/setting-up-pru-on-the-beaglebone-black/, 
and I'm able to execute am335x_pru_package examples with this output:

*INFO: Starting PRU_memAccessPRUDataRam example.*
*INFO: Initializing example.*
*INFO: Executing example.*
*INFO: Waiting for HALT command.*
*INFO: PRU completed transfer.*
*Example executed successfully.*

The problem comes when I want to do the same with c code examples that come 
in the sdk 
ti-processor-sdk-linux-am335x-evm-02.00.01.07/example-applications/pru-icss-4.0.1/examples/am335x.
 
I can compile them without error following some tips 
from http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs 
guide. 

The .out file from this compilation I transformed to binary with the 
following code:

*/opt/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/bin/hexpru 
/opt/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/bin.cmd pruSitara.out*

With this I get the data.bin and text.bin files that I use in the same main 
application code. But the output of this is

*INFO: Starting PRU_memAccessPRUDataRam example.*
*INFO: Initializing example.*
*INFO: Executing example.*
*INFO: Waiting for HALT command.*

The main application code is blocked at prussdrv_pru_wait_event. But I can 
see that the code into the PRU is running adding some leds on code into it. 
So the PRU code is executed and finished but the main application can`t get 
this event.

I am newbie, so I'll probably not considering something.Before posting more 
information about the code I am using in the examples, could you indicate 
me if I am following good steps to get run an application in the PRU called 
from the main application?

Thanks all!
Aitor

-- 
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] Looking for 3.8.13-bone30 headers deb file

[mmiller5560]

Thanks for responding so quickly. Really appreciate it. I will give it a 
try.

On Wednesday, March 23, 2016 at 9:03:19 AM UTC-5, RobertCNelson wrote:
>
> On Wed, Mar 23, 2016 at 7:47 AM,  > 
> wrote: 
> > I am trying to compile a patch for the c_can.ko and c_can_platform.ko 
> kernel 
> > modules for the BeagleBone Black 3.8.13-bone30 kernel. We used this 
> version 
> > a couple years ago to get started on our project and at this point are 
> > fairly committed to it. 
> > 
> > The problem that I'm having is locating the 3.8.13-bone30 header files. 
> The 
> > kernel image we used to install Debian on the BeagleBone only lists 
> headers 
> > for 3.2 and 2.6. I've come across a few older links for the 
> 3.8.13-bone30 
> > headers, but those don't seem to work anymore. 
> > 
> > The closest I've come is trying the debs here: 
> > https://rcn-ee.net/repos/debian/pool/main/l/linux-upstream/. But they 
> only 
> > run from bone64 to bone79. I was able to build the ko's using one of 
> them, 
> > but got "Invalid module format" when I tried to install. 
> > 
> > My skills are pretty limited when it comes to compiling LKMs. I 
> typically 
> > find the headers and build on the platform itself. Preferably using a 
> deb 
> > install that sets everything up for me. 
>
> from the archive on my nas: 
>
>
> http://rcn-ee.homeip.net:81/farm/testing/linux-headers-3.8.13-bone30_1.0wheezy_armhf.deb
>  
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

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

[beagleboard] Re: Should I bitbang i2c ?

[Christopher Hopwood]

Hi Anuja,

Sorry, it has been a very long time since I last worked with the PRU.  I 
honestly don't remember.  Maybe some more googling around will help?
Have you tried this? 
http://elinux.org/ECE497_BeagleBone_PRU#Building_and_Running_the_GPIO_PWM_PRU_Example

I got a fair bit of information from the elinux.org wiki.  I'm not sure 
what's right, but I would try getting that example working in the link 
above, and try to figure out what's different between your code and the 
example code that stops it from working.
Don't ignore search results with ECE497; it's the class ID for embedded 
linux at Rose-Hulman.  We worked with Beaglebones there.

Good luck!

On Wednesday, March 23, 2016 at 8:52:28 AM UTC-5, anujam...@gmail.com wrote:
>
> Hi,
>
> I am trying to toggle a GPO pin in mode GPIO using PRU.
>
> For achieving this, I enable OCP master port and then write to 
> GPIO_SETDATAOUT and GPIO_CLEARDATAOUT registers. 
> But, I can't see any output on pin. 
> The pin is configured in 0x07 mode in device tree overlay.
>
> Can you help me with this?
>  
> Thanks,
> Anuja
>
> On Saturday, 3 October 2015 00:37:40 UTC+2, Christopher Hopwood wrote:
>>
>>
>> https://github.com/Rose-Hulman-ROBO4xx/1314-BeagleBone-Quadcopter/tree/master_rev2/code/ControlAlgorithm/quadcopter_apps/imu
>>
>> On Friday, October 2, 2015 at 11:53:57 AM UTC-5, Mickae1 wrote:
>>>
>>> Hi, could you give me the link ? It's not working anymore
>>>
>>> Micka, ^^
>>>
>>> Le mardi 22 octobre 2013 07:10:17 UTC+2, Christopher Hopwood a écrit :

 I stopped trying to utilize the i2c modules and just bitbanged it 
 myself. If you need i2c bitbanging on the PRU, I can drop the link to the 
 git for it tomorrow. 
>>>
>>>

-- 
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] DTC issue with new kernel 4.1.18-bone-rt-r20

[Fabien Mousnier]

not the solution, same error, i really think that it's the dts file.

Le mercredi 23 mars 2016 14:55:52 UTC+1, Fabien Mousnier a écrit :
>
> I think i found the problem.
>
> i'm trying to compile a dts file provided by a dtbo file compile with the 
> old version of dtc.
>
> I'm looking for the original dts file to verify that.
>
> Le mercredi 23 mars 2016 14:34:08 UTC+1, Fabien Mousnier a écrit :
>>
>> Hi Robert,
>>
>> it's that i thinked on the fisrt time but it seems to be the good version 
>> : Version: DTC 1.4.1-g1e75ebc9
>>
>> that why i don't understand.
>>
>> Le mercredi 23 mars 2016 14:23:08 UTC+1, RobertCNelson a écrit :
>>>
>>> On Wed, Mar 23, 2016 at 8:01 AM, Fabien Mousnier  
>>> wrote: 
>>> > Hi everybody, 
>>> > 
>>> > There is my configuration : 
>>> > 
>>> > Beaglebone Black Rev.C 
>>> > kernel 4.1.18-bone-rt-r20 
>>> > DTV version 1.4.1-g1e75ebc9 
>>> > 
>>> > I'm tryin to update my plateform to new kernel 4.1 but it's seem to 
>>> have an 
>>> > issue when i load my dtbo file. (all is ok with a 3.8.13-bone73 
>>> kernel) 
>>>
>>> If it works on 3.8.x but not, 4.1.x, this means you didn't use the 
>>> correct version of dtc: 
>>>
>>> https://github.com/beagleboard/bb.org-overlays/ 
>>>
>>> Regards, 
>>>
>>> -- 
>>> Robert Nelson 
>>> https://rcn-ee.com/ 
>>>
>>

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

Re: [beagleboard] Looking for 3.8.13-bone30 headers deb file

[Robert Nelson]

On Wed, Mar 23, 2016 at 7:47 AM,   wrote:
> I am trying to compile a patch for the c_can.ko and c_can_platform.ko kernel
> modules for the BeagleBone Black 3.8.13-bone30 kernel. We used this version
> a couple years ago to get started on our project and at this point are
> fairly committed to it.
>
> The problem that I'm having is locating the 3.8.13-bone30 header files. The
> kernel image we used to install Debian on the BeagleBone only lists headers
> for 3.2 and 2.6. I've come across a few older links for the 3.8.13-bone30
> headers, but those don't seem to work anymore.
>
> The closest I've come is trying the debs here:
> https://rcn-ee.net/repos/debian/pool/main/l/linux-upstream/. But they only
> run from bone64 to bone79. I was able to build the ko's using one of them,
> but got "Invalid module format" when I tried to install.
>
> My skills are pretty limited when it comes to compiling LKMs. I typically
> find the headers and build on the platform itself. Preferably using a deb
> install that sets everything up for me.

from the archive on my nas:

http://rcn-ee.homeip.net:81/farm/testing/linux-headers-3.8.13-bone30_1.0wheezy_armhf.deb

Regards,

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

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

Re: [beagleboard] DTC issue with new kernel 4.1.18-bone-rt-r20

[Fabien Mousnier]

I think i found the problem.

i'm trying to compile a dts file provided by a dtbo file compile with the 
old version of dtc.

I'm looking for the original dts file to verify that.

Le mercredi 23 mars 2016 14:34:08 UTC+1, Fabien Mousnier a écrit :
>
> Hi Robert,
>
> it's that i thinked on the fisrt time but it seems to be the good version 
> : Version: DTC 1.4.1-g1e75ebc9
>
> that why i don't understand.
>
> Le mercredi 23 mars 2016 14:23:08 UTC+1, RobertCNelson a écrit :
>>
>> On Wed, Mar 23, 2016 at 8:01 AM, Fabien Mousnier  
>> wrote: 
>> > Hi everybody, 
>> > 
>> > There is my configuration : 
>> > 
>> > Beaglebone Black Rev.C 
>> > kernel 4.1.18-bone-rt-r20 
>> > DTV version 1.4.1-g1e75ebc9 
>> > 
>> > I'm tryin to update my plateform to new kernel 4.1 but it's seem to 
>> have an 
>> > issue when i load my dtbo file. (all is ok with a 3.8.13-bone73 kernel) 
>>
>> If it works on 3.8.x but not, 4.1.x, this means you didn't use the 
>> correct version of dtc: 
>>
>> https://github.com/beagleboard/bb.org-overlays/ 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

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

[beagleboard] Re: SPI BBB Master, BBB Slave

[yaron . lederman]

Hi,

Is there any resolution about this ? Since I'm having the same consideration

Thanks !


On Wednesday, November 4, 2015 at 4:15:23 PM UTC+2, ravi...@gmail.com wrote:
>
> Hi,
>
> I'm trying to setup SPI slave mode with same above method and 
> changed OMAP2_MCSPI_MODULCTRL_MS set to 0 for slave mode.
>
> i'm facing issue in master mode and slave both on sckl pin configuration. 
>
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV in this link why sckl 
> pin is configured as INPUT 0x33 but it will work with same configuration if 
> i change it to OUTPUT it doesn't work with any slave device and no clock on 
> that pin.
>
> Please anyone clarify this doubt and issues.
>
> For slave mode i tried to change OMAP2_MCSPI_MODULCTRL_MS bit in driver 
> file spi_omap2_mcspi.c but no use. still its master only. 
>
> Please provide any suggestion or exact procedure.
>
> Thank you in advance.
>
> Regard s
> Ravi 
>
> On Thursday, September 18, 2014 at 5:45:47 AM UTC+5:30, phil...@gmail.com 
> wrote:
>>
>>
>> I am having issues with SPI between two BBB that may be simple to solve. 
>> I have spidev_test loopback working on each board but am having problems 
>> connecting the two.
>>
>> spi0 master dts:
>>   0x150 0x10  /* spi0_sclk, OUTPUT_PULLUP | MODE0 */
>>   0x154 0x30  /* spi0_d0, INPUT_PULLUP | MODE0 */
>>   0x158 0x10  /* spi0_d1, OUTPUT_PULLUP | MODE0 */
>>   0x15c 0x10  /* spi0_cs0, OUTPUT_PULLUP | MODE0 */
>>
>> spi slave dts:
>>   0x150 0x30  /* spi0_sclk, INPUT_PULLUP | MODE0 */
>>   0x154 0x10  /* spi0_d0, OUTPUT_PULLUP | MODE0 */
>>   0x158 0x30  /* spi0_d1, INPUT_PULLUP | MODE0 */
>>   0x15c 0x30  /* spi0_cs0, INPUT_PULLUP | MODE0 */
>>
>>
>> The oscilloscope shows activity when spi0_sckl (P9_17) is not connected 
>> but nothing when P9_17 is connected between both boards. 
>> I am sending bytes from master with the command: echo 1 > /dev/spidev1.0
>>
>> I need 4-8mbit/sec transfer, is this achievable by bit banging over GPIO 
>> and would that be a viable alternative to getting SPI working?
>>
>>

-- 
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: Should I bitbang i2c ?

[anujamutalik]

Hi,

I am trying to toggle a GPO pin in mode GPIO using PRU.

For achieving this, I enable OCP master port and then write to 
GPIO_SETDATAOUT and GPIO_CLEARDATAOUT registers. 
But, I can't see any output on pin. 
The pin is configured in 0x07 mode in device tree overlay.

Can you help me with this?
 
Thanks,
Anuja

On Saturday, 3 October 2015 00:37:40 UTC+2, Christopher Hopwood wrote:
>
>
> https://github.com/Rose-Hulman-ROBO4xx/1314-BeagleBone-Quadcopter/tree/master_rev2/code/ControlAlgorithm/quadcopter_apps/imu
>
> On Friday, October 2, 2015 at 11:53:57 AM UTC-5, Mickae1 wrote:
>>
>> Hi, could you give me the link ? It's not working anymore
>>
>> Micka, ^^
>>
>> Le mardi 22 octobre 2013 07:10:17 UTC+2, Christopher Hopwood a écrit :
>>>
>>> I stopped trying to utilize the i2c modules and just bitbanged it 
>>> myself. If you need i2c bitbanging on the PRU, I can drop the link to the 
>>> git for it tomorrow. 
>>
>>

-- 
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] Looking for 3.8.13-bone30 headers deb file

[mmiller5560]

I am trying to compile a patch for the c_can.ko and c_can_platform.ko 
kernel modules for the BeagleBone Black 3.8.13-bone30 kernel. We used this 
version a couple years ago to get started on our project and at this point 
are fairly committed to it.

The problem that I'm having is locating the 3.8.13-bone30 header files. The 
kernel image we used to install Debian on the BeagleBone only lists headers 
for 3.2 and 2.6. I've come across a few older links for the 3.8.13-bone30 
headers, but those don't seem to work anymore.

The closest I've come is trying the debs 
here: https://rcn-ee.net/repos/debian/pool/main/l/linux-upstream/. But they 
only run from bone64 to bone79. I was able to build the ko's using one of 
them, but got "Invalid module format" when I tried to install.

My skills are pretty limited when it comes to compiling LKMs. I typically 
find the headers and build on the platform itself. Preferably using a deb 
install that sets everything up for me.

Any help would be greatly 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.

[beagleboard] DTC issue / Illegal property (size) 'fixup' @/__local_fixups__

[mousnier . f]

Hi everybody,

there is my config :

BBK Rev.C
OS ubuntu with Linux arm 4.1.18-bone-rt-r20
DTC 1.4.1-g1e75ebc9

i have an issue with my GSM internet cape, after compile my dtbo file with 
dtc, imposible to load it ! all OK ok on an Linux 3.8.13-bone73

Error message is :

[ 1257.261448] bone_capemgr bone_capemgr: part_number 'INTERNET-HUB', 
version 'N/A'
[ 1257.261513] bone_capemgr bone_capemgr: slot #7: override
[ 1257.261553] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 7
[ 1257.261594] bone_capemgr bone_capemgr: slot #7: 'Override Board 
Name,00A0,Override Manuf,INTERNET-HUB'
[ 1257.262806] __of_adjust_tree_phandle_references: Illegal property (size) 
'fixup' @/__local_fixups__
[ 1257.271937] bone_capemgr bone_capemgr: slot #7: Failed to resolve tree

Please have you an idea of what appened ?

Many thanks.

*PS : My dts file : INTERNET-HUB-00A0.dts*

/dts-v1/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
version = "00A0";
manufacturer = "EACH";
part-number = "INTERNET-HUB";
exclusive-use = "P9.25", "P9.27", "P9.42";

fragment@0 {
target = <0xdeadbeef>;

__overlay__ {

pinctrl_gpio_pins {
pinctrl-single,pins = <0x1ac 0x27 0x1a4 
0x27 0x164 0x7 0x1a0 0x7>;
linux,phandle = <0x1>;
phandle = <0x1>;
};
};
};

fragment@1 {
target = <0xdeadbeef>;

__overlay__ {
#address-cells = <0x1>;
#size-cells = <0x1>;

gpio {
compatible = "bone-pinmux-helper";
pinctrl-names = "default";
pinctrl-0 = <0x1>;
status = "okay";
};
};
};

__symbols__ {
pinctrl_gpio = "/fragment@0/__overlay__/pinctrl_gpio_pins";
};

__fixups__ {
am33xx_pinmux = "/fragment@0:target:0";
ocp = "/fragment@1:target:0";
};

__local_fixups__ {
fixup = "/fragment@1/__overlay__/gpio:pinctrl-0:0";
};
};


-- 
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] DTC issue with new kernel 4.1.18-bone-rt-r20

[Fabien Mousnier]

Hi Robert,

it's that i thinked on the fisrt time but it seems to be the good version 
: Version: DTC 1.4.1-g1e75ebc9

that why i don't understand.

Le mercredi 23 mars 2016 14:23:08 UTC+1, RobertCNelson a écrit :
>
> On Wed, Mar 23, 2016 at 8:01 AM, Fabien Mousnier  > wrote: 
> > Hi everybody, 
> > 
> > There is my configuration : 
> > 
> > Beaglebone Black Rev.C 
> > kernel 4.1.18-bone-rt-r20 
> > DTV version 1.4.1-g1e75ebc9 
> > 
> > I'm tryin to update my plateform to new kernel 4.1 but it's seem to have 
> an 
> > issue when i load my dtbo file. (all is ok with a 3.8.13-bone73 kernel) 
>
> If it works on 3.8.x but not, 4.1.x, this means you didn't use the 
> correct version of dtc: 
>
> https://github.com/beagleboard/bb.org-overlays/ 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

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

Re: [beagleboard] image-builder fails to produce image

[Robert Nelson]

On Wed, Mar 23, 2016 at 8:19 AM, ARNOLD ILKYOUNG KWOUN  wrote:
> Hello, folks,
>
> I am trying to build my own custom image to boot my beagleboard-xm.
>
> When I pulled latest image-builder from github and tried to run the stript
> with the command './RootStock-NG.sh -c rcn-ee_console_ubuntu_xenial_armhf',
> it ended up with the following error message;
>
> ~~~
> update-initramfs: Generating /boot/initrd.img-4.1.18-ti-r53
> Log: (chroot): system_tweaks
> Log: (chroot): set_locale
> Log: (chroot) Ubuntu: setting up locales: [en_US.UTF-8]
> Generating locales (this might take a while)...
>   en_US.UTF-8... done
> Generation complete.
> Log: (chroot): manual_deborphan
> Log: (chroot): add_user
> i2c:x:111:
> kmem:x:15:
> netdev:x:108:
> systemd-journal:x:101:
> Log: (chroot) adding admin group to /etc/sudoers
> ubuntu:x:1000:1000:Demo User:/home/ubuntu:/bin/bash
> passwd: password expiry information changed.
> Log: (chroot): startup_script
> Log: (chroot): ubuntu_startup_script
> qemu: Unsupported syscall: 384
> Created symlink
> /etc/systemd/system/multi-user.target.wants/generic-board-startup.service,
> pointing to /lib/systemd/system/generic-board-startup.service.
> qemu: Unsupported syscall: 384
> Created symlink /etc/systemd/system/multi-user.target.wants/capemgr.service,
> pointing to /lib/systemd/system/capemgr.service.
> Log: (chroot) Warning, qemu can fail here... (run on real armv7l hardware
> for production images)
> Log: (chroot): [git clone https://github.com/RobertCNelson/boot-scripts
> /opt/scripts/ --depth 1]
> Cloning into '/opt/scripts'...
> POST git-upload-pack (155 bytes)
> POST git-upload-pack (164 bytes)
> remote: Counting objects: 119, done.
> remote: Compressing objects: 100% (97/97), done.
> remote: Total 119 (delta 26), reused 60 (delta 10), pack-reused 0
> Receiving objects: 100% (119/119), 298.43 KiB | 204.00 KiB/s, done.
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> error: --shallow-file died of signal 11
> fatal: index-pack failed

qemu failure on x86, this is normal-ish 50% of the time..

Try running it a second time..

Otherwise, invest in a real arm builder.

Regards,

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

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

Re: [beagleboard] DTC issue with new kernel 4.1.18-bone-rt-r20

[Robert Nelson]

On Wed, Mar 23, 2016 at 8:01 AM, Fabien Mousnier  wrote:
> Hi everybody,
>
> There is my configuration :
>
> Beaglebone Black Rev.C
> kernel 4.1.18-bone-rt-r20
> DTV version 1.4.1-g1e75ebc9
>
> I'm tryin to update my plateform to new kernel 4.1 but it's seem to have an
> issue when i load my dtbo file. (all is ok with a 3.8.13-bone73 kernel)

If it works on 3.8.x but not, 4.1.x, this means you didn't use the
correct version of dtc:

https://github.com/beagleboard/bb.org-overlays/

Regards,

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

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

[beagleboard] DTC issue with new kernel 4.1.18-bone-rt-r20

[Fabien Mousnier]

Hi everybody,

There is my configuration :

Beaglebone Black Rev.C
kernel 4.1.18-bone-rt-r20
DTV version 1.4.1-g1e75ebc9

I'm tryin to update my plateform to new kernel 4.1 but it's seem to have an 
issue when i load my dtbo file. (all is ok with a 3.8.13-bone73 kernel)

*There is the error output in dmesg :*

[  189.772569] bone_capemgr bone_capemgr: part_number 'INTERNET-HUB', 
version 'N/A'
[  189.772633] bone_capemgr bone_capemgr: slot #5: override
[  189.772672] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 5
[  189.772712] bone_capemgr bone_capemgr: slot #5: 'Override Board 
Name,00A0,Override Manuf,INTERNET-HUB'
[  189.776974] __of_adjust_tree_phandle_references: Illegal property (size) 
'fixup' @/__local_fixups__
[  189.786246] bone_capemgr bone_capemgr: slot #5: Failed to resolve tree

My dts file :

/dts-v1/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
version = "00A0";
manufacturer = "EACH";
part-number = "INTERNET-HUB";
exclusive-use = "P9.25", "P9.27", "P9.42";

fragment@0 {
target = <0xdeadbeef>;

__overlay__ {

pinctrl_gpio_pins {
pinctrl-single,pins = <0x1ac 0x27 0x1a4 
0x27 0x164 0x7 0x1a0 0x7>;
linux,phandle = <0x1>;
phandle = <0x1>;
};
};
};

fragment@1 {
target = <0xdeadbeef>;

__overlay__ {
#address-cells = <0x1>;
#size-cells = <0x1>;

gpio {
compatible = "bone-pinmux-helper";
pinctrl-names = "default";
pinctrl-0 = <0x1>;
status = "okay";
};
};
};

__symbols__ {
pinctrl_gpio = "/fragment@0/__overlay__/pinctrl_gpio_pins";
};

__fixups__ {
am33xx_pinmux = "/fragment@0:target:0";
ocp = "/fragment@1:target:0";
};

__local_fixups__ {
fixup = "/fragment@1/__overlay__/gpio:pinctrl-0:0";
};
};


Please, can you help me to understand what appened ?

Many thanks.


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

Re: [beagleboard] Re: PinMuxing P9_21 and P9_23 to I2C2?

[Graham Haddock]

PCB rework skills are very useful, and not explicitly taught in college.
Good luck with your project.
--- Graham

==

On Wed, Mar 23, 2016 at 3:13 AM, Christopher Earley 
wrote:

> That bit about only being able to mux a specific mode's signal (e.g.
> I2C2_SDA or I2C2_SCL) to one pin at a time is the clincher. I didn't feel
> it vital to state in my intro post but turning off the default I2C2 bus
> pins would mean losing the Seeed I2C2 Grove connector (which is connected
> to P9-19 and 20) on the BeagleBone Green. Since that port is also in use
> for my demos, a software solution is just not in the cards for working
> around my poor design decision.
>
> I'll brush up on my PCB rework skills as you discussed and push forward
> with the intent to come back to learning about the BeagleBone's device tree
> system at a later date.
>
> Thanks for your help, Graham and wish me luck!
>
> --
> 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/rjWUlnwe8n8/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: PinMuxing P9_21 and P9_23 to I2C2?

[Christopher Earley]

That bit about only being able to mux a specific mode's signal (e.g. 
I2C2_SDA or I2C2_SCL) to one pin at a time is the clincher. I didn't feel 
it vital to state in my intro post but turning off the default I2C2 bus 
pins would mean losing the Seeed I2C2 Grove connector (which is connected 
to P9-19 and 20) on the BeagleBone Green. Since that port is also in use 
for my demos, a software solution is just not in the cards for working 
around my poor design decision.

I'll brush up on my PCB rework skills as you discussed and push forward 
with the intent to come back to learning about the BeagleBone's device tree 
system at a later date.

Thanks for your help, Graham and wish me luck!

-- 
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: PinMuxing P9_21 and P9_23 to I2C2?

[Christopher Earley]

That bit about only being able to mux a specific mode's signal (e.g. 
I2C2_SDA or I2C2_SCL) to one pin at a time is the clincher. I didn't feel 
it vital to state in my intro post but turning off the default I2C2 bus 
pins would mean losing the Seeed I2C2 Grove connector (which is connected 
to P9-19 and 20) on the BeagleBone Green. Since that port is also in use 
for my demos, a software solution is just not in the cards for working 
around my poor design decision.

I'll brush up on my PCB rework skills as you discussed and push forward 
with the intent to come back to learning about the BeagleBone's device tree 
system at a later date.

Thanks for your help, Graham and wish me luck!

On Tuesday, March 22, 2016 at 10:24:00 PM UTC-5, Graham wrote:
>
> If you understand device trees, you should be able to turn off I2C2 on 
> p9-19 and P9-20 and enable on P9-21 and P9-22 (as Mode 4).  I doubt that 
> you can route the I2C2 out to two separate pin-outs at the same time.
>
> If you don't understand how to make all of that work, then I would put 
> some very short jumper wires from P9-19 to the next pin, which is P9-21 and 
> another short jumper from P9-20 to P9-22. I2C2 is enabled and live by 
> default on Pins P9-19 and -20 on the current 8.3 releases.  If you don't 
> know how to turn off P9-21 and P9-22 for the jumper solution, cut the 
> connector pins off going from the cape to the main BBB board.  Spend the 
> rest of the time between now and the 31st finishing the rest of the 
> project.  You probably have other problems that you don't even know you 
> have, yet.
>
> --- Graham
>
> ==
>
> On Tuesday, March 22, 2016 at 10:05:59 AM UTC-5, Christopher Earley wrote:
>>
>>
>> As stated in the topic's subject, I am currently trying to expose I2C2 
>> (The I2C bus that's normally connected to P9_19, P9_20) to pins P9_21 and 
>> P9_22. Since the documentation for the Beaglebone Black/Green show that 
>> pins 21 and 22 can be used for I2C2 it must be possible, I just can't find 
>> a solid way to do it.
>>
>> *Background Info*
>>
>> Hardware: Seeed BeagleBone Green
>> OS: debian
>> uname -a: Linux beaglebone 3.8.13-bone71.1 #1 SMP Wed May 20 20:13:27 PDT 
>> 2015 armv7l GNU/Linux
>> (Note that I am willing to flash whatever OS/kernel version it takes to 
>> get this working)
>>
>> The requirement comes from an error I made not knowing about the default 
>> I2C device tree settings for the device. Since there were two pairs of I2C2 
>> pins listed in the documentation, I chose the pair that lad less overlap, 
>> which was a mistake. I have since then fixed the error in my 
>> schematic/board but I already have demo PCBs on the way from the fabhouse. 
>> It'd be great to just expose those pins to the I2C bus rather than cut and 
>> rewire traces manually. Sadly due to the time constraints for the project 
>> (Deadline is on the 31st) I cannot send out for an updated PCB.
>>
>> The software side of this project is based on the Adafruit_BBIO library 
>> which is, in turn, based on the python smbus library. There's very little 
>> in terms of configuration when setting up I2C communication with those 
>> libraries so the magic switch is most likely not there.
>>
>> *Main Methods Attempted*
>>
>> For all cases, assume that the UART2 device tree overlay has been 
>> disabled via blacklisting in uEnv.txt and a reboot.
>>
>>
>>- bonescript pinMode() - Does nothing to the mode of the pin in this 
>>case although getPinMode() does show that I2C2_SDA/SCL is a possible mode 
>>option.
>>
>>
>>- Enabling an I2C2 device tree overlay from the bb.org-overlays 
>>
>> 
>>  
>>repo that I edited to point to P9_21 and P9_22 
>> instead of the normal I2C2 pins. This 
>>compiles and shows up in the cape manager after inclusion but nothing 
>>happens on pins P9_21 and P9_22 when I try to communicate to my PCA9685 
>>devboard. Meanwhile pins P9_19, P9_20 work just fine so the bus is still 
>>functional.
>>
>>
>>- Tried Bernhard Tittelbach's lovely Device-Tree Overlay Generator 
>>
>> to
>>  
>>make a setting file for each pin.
>>
>>
>>- Mucked around with the Universal Cape overlay but it never really 
>>seemed to change any pin states in this case.
>>
>>
>> *Summary*
>>
>> Given any possible (supported) OS, how can I get pins P9_21 and P9_22 
>> into the correct pin mode to mux to the I2C2 device?
>> And is it possible to have I2C2 exposed on both P9_19,20 and P9_21,22?
>>
>> Lastly, I apologize for any confusing nomenclature. I've been flashing 
>> different OS versions and reading documentation relevant to differing 
>> flavors of debian trying to solve this that I'm a bit number-dizzy.
>>
>> Thanks for your time!
>>
>

-- 
For more options, visit http://be