[beagleboard] Suggestion for connecting multiple components to Beaglebone black through usb.

[rakesh . kondeti]

Hello,

   I am working on a project, in which beaglebone black is used. The 
components to be connected to beaglebone black are Sensehub (which consists 
of accelerometer) and a webcam.As sensehub cannot be directly connected to 
beaglebone black directly, we connected it to launch-XL, which in turn to 
be connected to beaglebone black through USB. The real problem comes here. 
Now, the webcam should also be connected to beaglebone through USB. But, 
the beaglebone black is provided with only one USB slot. So, we are only 
able to connect one of the either components (webcam or Launch-XL) to 
beaglebone black.

*  So, how multiple components are connected to beaglebone black 
through USB?*


Regards,
Rakesh Reddy.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e4966bfb-9c98-497d-96b9-7f4356d5a2a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Enable UART pins on BBB with Ubuntu 16.04 Kernel 4.4.68

[salahgafoor]

Hello,

I've also faced the same issue.

Even though I tried editing the /boot/uEnv.txt file, I cannot enable uart

cape_enable=bone_capemgr.enable_partno=BB-UART2


I had to use 
config-pin P9_21 uart
config-pin P9_22 uart

to enable my uart2 channel.

@Zach : Please try the same and let me know. I don't know if it will work 
in Ubuntu.

@Robert or anyone else, why enabling uart in uEnv.txt is not successful 
always?


On Friday, 18 August 2017 02:51:05 UTC+5:30, Zach wrote:
>
> Hello there, I am attempting to activate UART pins on the BeagleBone Black 
> with Ubuntu 16.04 kernel 4.4.68
>
> ubuntu@arm:~$ uname -a
> Linux arm 4.4.68-ti-r111 #1 SMP Wed Jun 28 13:40:31 UTC 2017 armv7l armv7l 
> armv7l GNU/Linux
>
> I have tried editing the /boot/uEnv.txt file.
>
> cape_enable=bone_capemgr.enable_partno=BB-UART1
>
>
> I have tried 
> echo BB-UART1 > /sys/devices/platform/bone_capemgr/slots
>
> Which causes the BBB to stall, I even let it sit for almost 2 hours once 
> to no results.
>
> ubuntu@arm:~$ ls -l /dev/ttyO*
> lrwxrwxrwx 1 root root 5 Jul 14 14:48 /dev/ttyO0 -> ttyS0
> lrwxrwxrwx 1 root root 5 Jul 14 14:48 /dev/ttyO1 -> ttyS1
> lrwxrwxrwx 1 root root 5 Jul 14 14:48 /dev/ttyO2 -> ttyS2
> lrwxrwxrwx 1 root root 5 Jul 14 14:48 /dev/ttyO4 -> ttyS4
> ubuntu@arm:~$ ls -l /dev/ttyS*
> crw--w 1 root tty 4, 64 Jul 14 14:48 /dev/ttyS0
> crw-rw 1 root dialout 4, 65 Jul 14 14:48 /dev/ttyS1
> crw-rw 1 root dialout 4, 66 Jul 14 14:48 /dev/ttyS2
> crw-rw 1 root dialout 4, 67 Jul 14 14:48 /dev/ttyS3
> crw-rw 1 root dialout 4, 68 Jul 14 14:48 /dev/ttyS4
> crw-rw 1 root dialout 4, 69 Jul 14 14:48 /dev/ttyS5
>
>
>
> I have tried 
> config-pin 911 uart
> config pin 913 uart
> ubuntu@arm:~$ config-pin -q 911
> P9_11 Mode: uart
> ubuntu@arm:~$ config-pin -q 913
> P9_13 Mode: uart
>
> But still no data being transferred.  My end goal is to use ROS with a 
> PixHawk for drone flights.  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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/04c14572-ce48-426b-b3ef-b3f6772c1eae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Configuring GPIO pins as active high

[salahgafoor]

Thanks @Robert

I could solve the issue by setting active_low value in 
/sys/class/gpio/gpio66

But I think that's not the recommended method.

Comments please!!

On Friday, 23 February 2018 18:06:48 UTC+5:30, Salah Abdul Gafoor wrote:
>
> Hi,
>
> I want to configure some of my gpio pins (P8_07 to P8_10) of my beagle 
> bone black revC board as inputs with active high state.
>
> OS running in my board is Debian 9.3, with Kernel 4.1.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4687d4f5-b329-4937-b246-ec8714c749b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Disconnect HDMI cape from Cape Manager

[Kenny Koller]

By this I mean I have my uEnv.txt configured in this way and I see these 
messages. Not that it fixed it. Thanks.

On Monday, February 26, 2018 at 7:10:39 PM UTC-8, Kenny Koller wrote:
>
> Thanks. I had a line in there to disable it but have commented it out.
>
>
> uname_r=3.8.13-bone62
>
>
> optargs=quiet drm.debug=7
>
>
> findfdt=setenv fdtfile am335x-boneblack.dtb
>
>
> cape_enable=capemgr.enable_partno=BB-SPIDEV0
>
>
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>
>
>
>
> On Monday, February 26, 2018 at 7:06:12 PM UTC-8, Wulf Man wrote:
>>
>> Check /boot/uEnv.txt to see if its being loaded in there
>>
>>
>> On 2/26/2018 8:04 PM, Kenny Koller wrote:
>>
>> I am running the 3.8 kernel on an Arrow Beaglebone Black Industrial. I 
>> have rebuilt the device tree blob to exclude HDMI but I still see the error 
>> messages below. What is the best way to stop these from occuring? Are there 
>> configuration files for the cape manager? 
>>
>> Thanks
>>
>> Duchess: dmesg | grep HDMI
>>> [0.701013] bone-capemgr bone_capemgr.9: slot #5: 
>>> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
>>> [0.701113] bone-capemgr bone_capemgr.9: slot #6: 
>>> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
>>> [0.701654] bone-capemgr bone_capemgr.9: loader: before slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [0.701667] bone-capemgr bone_capemgr.9: loader: check slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [0.701737] bone-capemgr bone_capemgr.9: loader: before slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [0.701750] bone-capemgr bone_capemgr.9: loader: check slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [0.702354] bone-capemgr bone_capemgr.9: loader: check slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [0.704458] bone-capemgr bone_capemgr.9: loader: check slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [0.726410] bone-capemgr bone_capemgr.9: loader: check slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [0.726453] bone-capemgr bone_capemgr.9: loader: check slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [0.726467] bone-capemgr bone_capemgr.9: loader: after slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [0.726483] bone-capemgr bone_capemgr.9: slot #5: Requesting part 
>>> number/version based 'BB-BONELT-HDMI-00A0.dtbo
>>> [0.726499] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 
>>> 'BB-BONELT-HDMI-00A0.dtbo' for board-name 'Bone-Black-HDMI', version '00A0'
>>> [0.999594] bone-capemgr bone_capemgr.9: failed to load firmware 
>>> 'BB-BONELT-HDMI-00A0.dtbo'
>>> [1.008403] bone-capemgr bone_capemgr.9: loader: failed to load 
>>> slot-5 BB-BONELT-HDMI:00A0 (prio 1)
>>> [1.019624] bone-capemgr bone_capemgr.9: loader: check slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [1.046607] bone-capemgr bone_capemgr.9: loader: check slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [1.046626] bone-capemgr bone_capemgr.9: loader: after slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [1.046643] bone-capemgr bone_capemgr.9: slot #6: Requesting part 
>>> number/version based 'BB-BONELT-HDMIN-00A0.dtbo
>>> [1.046661] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 
>>> 'BB-BONELT-HDMIN-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version 
>>> '00A0'
>>> [1.593939] bone-capemgr bone_capemgr.9: failed to load firmware 
>>> 'BB-BONELT-HDMIN-00A0.dtbo'
>>> [1.602870] bone-capemgr bone_capemgr.9: loader: failed to load 
>>> slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
>>>
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/70798894-b508-499e-92c8-ba663297e275%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a24fa56c-f1da-46b8-a82e-810cf28898cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Disconnect HDMI cape from Cape Manager

[Kenny Koller]

Thanks. I had a line in there to disable it but have commented it out.


uname_r=3.8.13-bone62


optargs=quiet drm.debug=7


findfdt=setenv fdtfile am335x-boneblack.dtb


cape_enable=capemgr.enable_partno=BB-SPIDEV0


#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN




On Monday, February 26, 2018 at 7:06:12 PM UTC-8, Wulf Man wrote:
>
> Check /boot/uEnv.txt to see if its being loaded in there
>
>
> On 2/26/2018 8:04 PM, Kenny Koller wrote:
>
> I am running the 3.8 kernel on an Arrow Beaglebone Black Industrial. I 
> have rebuilt the device tree blob to exclude HDMI but I still see the error 
> messages below. What is the best way to stop these from occuring? Are there 
> configuration files for the cape manager? 
>
> Thanks
>
> Duchess: dmesg | grep HDMI
>> [0.701013] bone-capemgr bone_capemgr.9: slot #5: 
>> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
>> [0.701113] bone-capemgr bone_capemgr.9: slot #6: 
>> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
>> [0.701654] bone-capemgr bone_capemgr.9: loader: before slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [0.701667] bone-capemgr bone_capemgr.9: loader: check slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [0.701737] bone-capemgr bone_capemgr.9: loader: before slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [0.701750] bone-capemgr bone_capemgr.9: loader: check slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [0.702354] bone-capemgr bone_capemgr.9: loader: check slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [0.704458] bone-capemgr bone_capemgr.9: loader: check slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [0.726410] bone-capemgr bone_capemgr.9: loader: check slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [0.726453] bone-capemgr bone_capemgr.9: loader: check slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [0.726467] bone-capemgr bone_capemgr.9: loader: after slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [0.726483] bone-capemgr bone_capemgr.9: slot #5: Requesting part 
>> number/version based 'BB-BONELT-HDMI-00A0.dtbo
>> [0.726499] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 
>> 'BB-BONELT-HDMI-00A0.dtbo' for board-name 'Bone-Black-HDMI', version '00A0'
>> [0.999594] bone-capemgr bone_capemgr.9: failed to load firmware 
>> 'BB-BONELT-HDMI-00A0.dtbo'
>> [1.008403] bone-capemgr bone_capemgr.9: loader: failed to load slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [1.019624] bone-capemgr bone_capemgr.9: loader: check slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [1.046607] bone-capemgr bone_capemgr.9: loader: check slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [1.046626] bone-capemgr bone_capemgr.9: loader: after slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [1.046643] bone-capemgr bone_capemgr.9: slot #6: Requesting part 
>> number/version based 'BB-BONELT-HDMIN-00A0.dtbo
>> [1.046661] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 
>> 'BB-BONELT-HDMIN-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version 
>> '00A0'
>> [1.593939] bone-capemgr bone_capemgr.9: failed to load firmware 
>> 'BB-BONELT-HDMIN-00A0.dtbo'
>> [1.602870] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>>
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/70798894-b508-499e-92c8-ba663297e275%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f97298c7-e3b2-4f23-b947-2f55190b4a45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Disconnect HDMI cape from Cape Manager

[evilwulfie]

Check /boot/uEnv.txt to see if its being loaded in there


On 2/26/2018 8:04 PM, Kenny Koller wrote:
> I am running the 3.8 kernel on an Arrow Beaglebone Black Industrial. I
> have rebuilt the device tree blob to exclude HDMI but I still see the
> error messages below. What is the best way to stop these from
> occuring? Are there configuration files for the cape manager?
>
> Thanks
>
> Duchess: dmesg | grep HDMI
> [    0.701013] bone-capemgr bone_capemgr.9: slot #5:
> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
> [    0.701113] bone-capemgr bone_capemgr.9: slot #6:
> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
> [    0.701654] bone-capemgr bone_capemgr.9: loader: before slot-5
> BB-BONELT-HDMI:00A0 (prio 1)
> [    0.701667] bone-capemgr bone_capemgr.9: loader: check slot-5
> BB-BONELT-HDMI:00A0 (prio 1)
> [    0.701737] bone-capemgr bone_capemgr.9: loader: before slot-6
> BB-BONELT-HDMIN:00A0 (prio 2)
> [    0.701750] bone-capemgr bone_capemgr.9: loader: check slot-6
> BB-BONELT-HDMIN:00A0 (prio 2)
> [    0.702354] bone-capemgr bone_capemgr.9: loader: check slot-5
> BB-BONELT-HDMI:00A0 (prio 1)
> [    0.704458] bone-capemgr bone_capemgr.9: loader: check slot-6
> BB-BONELT-HDMIN:00A0 (prio 2)
> [    0.726410] bone-capemgr bone_capemgr.9: loader: check slot-6
> BB-BONELT-HDMIN:00A0 (prio 2)
> [    0.726453] bone-capemgr bone_capemgr.9: loader: check slot-5
> BB-BONELT-HDMI:00A0 (prio 1)
> [    0.726467] bone-capemgr bone_capemgr.9: loader: after slot-5
> BB-BONELT-HDMI:00A0 (prio 1)
> [    0.726483] bone-capemgr bone_capemgr.9: slot #5: Requesting
> part number/version based 'BB-BONELT-HDMI-00A0.dtbo
> [    0.726499] bone-capemgr bone_capemgr.9: slot #5: Requesting
> firmware 'BB-BONELT-HDMI-00A0.dtbo' for board-name
> 'Bone-Black-HDMI', version '00A0'
> [    0.999594] bone-capemgr bone_capemgr.9: failed to load
> firmware 'BB-BONELT-HDMI-00A0.dtbo'
> [    1.008403] bone-capemgr bone_capemgr.9: loader: failed to load
> slot-5 BB-BONELT-HDMI:00A0 (prio 1)
> [    1.019624] bone-capemgr bone_capemgr.9: loader: check slot-6
> BB-BONELT-HDMIN:00A0 (prio 2)
> [    1.046607] bone-capemgr bone_capemgr.9: loader: check slot-6
> BB-BONELT-HDMIN:00A0 (prio 2)
> [    1.046626] bone-capemgr bone_capemgr.9: loader: after slot-6
> BB-BONELT-HDMIN:00A0 (prio 2)
> [    1.046643] bone-capemgr bone_capemgr.9: slot #6: Requesting
> part number/version based 'BB-BONELT-HDMIN-00A0.dtbo
> [    1.046661] bone-capemgr bone_capemgr.9: slot #6: Requesting
> firmware 'BB-BONELT-HDMIN-00A0.dtbo' for board-name
> 'Bone-Black-HDMIN', version '00A0'
> [    1.593939] bone-capemgr bone_capemgr.9: failed to load
> firmware 'BB-BONELT-HDMIN-00A0.dtbo'
> [    1.602870] bone-capemgr bone_capemgr.9: loader: failed to load
> slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
>
>
> -- 
> 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
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/70798894-b508-499e-92c8-ba663297e275%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/20627e7e-a841-d9e7-82dc-d178022c5d02%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Disconnect HDMI cape from Cape Manager

[Kenny Koller]

I am running the 3.8 kernel on an Arrow Beaglebone Black Industrial. I have 
rebuilt the device tree blob to exclude HDMI but I still see the error 
messages below. What is the best way to stop these from occuring? Are there 
configuration files for the cape manager?

Thanks

Duchess: dmesg | grep HDMI
> [0.701013] bone-capemgr bone_capemgr.9: slot #5: 
> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
> [0.701113] bone-capemgr bone_capemgr.9: slot #6: 
> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
> [0.701654] bone-capemgr bone_capemgr.9: loader: before slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.701667] bone-capemgr bone_capemgr.9: loader: check slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.701737] bone-capemgr bone_capemgr.9: loader: before slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [0.701750] bone-capemgr bone_capemgr.9: loader: check slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [0.702354] bone-capemgr bone_capemgr.9: loader: check slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.704458] bone-capemgr bone_capemgr.9: loader: check slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [0.726410] bone-capemgr bone_capemgr.9: loader: check slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [0.726453] bone-capemgr bone_capemgr.9: loader: check slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.726467] bone-capemgr bone_capemgr.9: loader: after slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.726483] bone-capemgr bone_capemgr.9: slot #5: Requesting part 
> number/version based 'BB-BONELT-HDMI-00A0.dtbo
> [0.726499] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 
> 'BB-BONELT-HDMI-00A0.dtbo' for board-name 'Bone-Black-HDMI', version '00A0'
> [0.999594] bone-capemgr bone_capemgr.9: failed to load firmware 
> 'BB-BONELT-HDMI-00A0.dtbo'
> [1.008403] bone-capemgr bone_capemgr.9: loader: failed to load slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [1.019624] bone-capemgr bone_capemgr.9: loader: check slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [1.046607] bone-capemgr bone_capemgr.9: loader: check slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [1.046626] bone-capemgr bone_capemgr.9: loader: after slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [1.046643] bone-capemgr bone_capemgr.9: slot #6: Requesting part 
> number/version based 'BB-BONELT-HDMIN-00A0.dtbo
> [1.046661] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 
> 'BB-BONELT-HDMIN-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version 
> '00A0'
> [1.593939] bone-capemgr bone_capemgr.9: failed to load firmware 
> 'BB-BONELT-HDMIN-00A0.dtbo'
> [1.602870] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/70798894-b508-499e-92c8-ba663297e275%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] RE: how can we tell system to shutdown on a power fail, using systemd and apcid

[evilwulfie]

seems they omitted the "AC" interrupt in the patch

https://patchwork.kernel.org/patch/9782813/

therefore the system will not power down on power fail like it used to













-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2213774c-f903-8720-deb6-2c1c437f9d91%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Using Playstation Eye's microphone array on Beaglebone Blue

[danbing....@gmail.com]

Hi,

So I am trying to use Playstation Eye's microphone array to perform some 
sound source localization tasks on my beaglebone blue.

I am using an ubuntu image from: https://jh.app.box.com/v/530-707-Dropbox

And I am using a software called HARK: https://www.hark.jp/

I suspect Playstation Eye is not working because when I try to use arecord 
command like:

arecord -D plughw:CARD=CameraB409241,DEV=0 -d 10 /tmp/test-mic.wav

to record a .wav file with playstation eye plugged in, it creates a .wav 
file (whose size is fixed, I remember it's 44 bytes)and never ends.

When I run the command with a regular webcam plugged in, it exits normally 
with the audio file saved.

I am wondering if anyone else has worked on similar topic before.

Thank you!

Best,
Danbing

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8ce8ad4f-859b-424c-889c-a0518c03b49b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

The IIO ADC driver can run at 800K samples per second. Here is the patch that 
made that possible. 

https://patchwork.kernel.org/patch/9391487/

I can confirm that I have tested the driver at 800Ksps and it works fine as 
long as you have a proper low impedance source for each ADC channel. CPU 
utilization was about 5% if I recall and that was probably used by the iiod 
daemon, which I used to display the waveform on a remote Linux app. 

There is example code in the original Starterware for McSPI, which should work 
fine if you are using the PRU low level drivers. 

Regards,
John




> On Feb 26, 2018, at 12:56 PM, pierrick.ra...@gadz.org wrote:
> 
> Thanks John, 
> 
> I am now working with the starterware_PRU but i did not find examples for 
> using the McSPI with the PRU, do you think it will be hard to adapt the 
> initial code to the PRU ? 
> By the way, looking to the IIO driver documentation, it seems that for the 
> AM335x chip the max sampling rate is only 200k samples per second which may 
> not be enough :
> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_Users_Guide ; am I 
> right ? 
> 
> 
> Thanks 
> 
> Pierrick 
> 
> Le lundi 19 février 2018 23:15:50 UTC-5, john3909 a écrit :
> Like I said, it was based on Starterware, so search Github for starterware 
> and you will see a project starterware_PRU. It does use the mcspi, so it is 
> not a bitbang implementation. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Feb 19, 2018, at 7:33 PM, pierric...@gadz.org <> wrote:
>> 
>> Thanks John for you answer, I was quit busy last week so I worked on this 
>> during the Weekend. 
>> 
>> Unfortunately, I was not able to find a project that is using the SPI and 
>> I2C interface with the PRU, I only found this one : 
>> https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki/SPI-Master-Controller 
>> 
>>  
>> But it is using bit banging for the SPI part and not using the on-board 
>> pull-up resistors for the I2C part.
>> 
>> Concerning the ADC, I'll have a loook at the UIIO drivers in the coming days 
>> it seems that it meets my need in term of real-time acquisition. 
>> 
>> Regards,
>> 
>> Pierrick 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> 
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/74949832-b67c-430f-811e-f3b2fff83852%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/3dc611e5-04e7-45bb-87d4-3c21a5665cec%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/14F65A4F-6A27-48D2-83CA-A61E2EEB833B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[pierrick . rauby]

Thanks John, 

I am now working with the starterware_PRU but I did not find examples for 
using the McSPI with the PRU, do you think it will be hard to adapt the 
initial code to the PRU ?

Thanks 

Pierrick 

Le lundi 19 février 2018 23:15:50 UTC-5, john3909 a écrit :
>
> Like I said, it was based on Starterware, so search Github for starterware 
> and you will see a project starterware_PRU. It does use the mcspi, so it is 
> not a bitbang implementation. 
>
> Regards,
> John
>
>
>
>
> On Feb 19, 2018, at 7:33 PM, pierric...@gadz.org  wrote:
>
> Thanks John for you answer, I was quit busy last week so I worked on this 
> during the Weekend. 
>
> Unfortunately, I was not able to find a project that is using the SPI and 
> I2C interface with the PRU, I only found this one : 
>
> https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki/SPI-Master-Controller 
> But it is using bit banging for the SPI part and not using the on-board 
> pull-up resistors for the I2C part.
>
> Concerning the ADC, I'll have a loook at the UIIO drivers in the coming 
> days it seems that it meets my need in term of real-time acquisition. 
>
> Regards,
>
> Pierrick 
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/74949832-b67c-430f-811e-f3b2fff83852%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/24b93589-561e-47b6-924c-ba8502bae837%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[pierrick . rauby]

Thanks John, 

I am now working with the starterware_PRU but i did not find examples for 
using the McSPI with the PRU, do you think it will be hard to adapt the 
initial code to the PRU ? 
By the way, looking to the IIO driver documentation, it seems that for the 
AM335x chip the max sampling rate is only 200k samples per second which may 
not be enough :
http://processors.wiki.ti.com/index.php/Linux_Core_ADC_Users_Guide ; am I 
right ? 


Thanks 

Pierrick 

Le lundi 19 février 2018 23:15:50 UTC-5, john3909 a écrit :
>
> Like I said, it was based on Starterware, so search Github for starterware 
> and you will see a project starterware_PRU. It does use the mcspi, so it is 
> not a bitbang implementation. 
>
> Regards,
> John
>
>
>
>
> On Feb 19, 2018, at 7:33 PM, pierric...@gadz.org  wrote:
>
> Thanks John for you answer, I was quit busy last week so I worked on this 
> during the Weekend. 
>
> Unfortunately, I was not able to find a project that is using the SPI and 
> I2C interface with the PRU, I only found this one : 
>
> https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki/SPI-Master-Controller 
> But it is using bit banging for the SPI part and not using the on-board 
> pull-up resistors for the I2C part.
>
> Concerning the ADC, I'll have a loook at the UIIO drivers in the coming 
> days it seems that it meets my need in term of real-time acquisition. 
>
> Regards,
>
> Pierrick 
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/74949832-b67c-430f-811e-f3b2fff83852%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3dc611e5-04e7-45bb-87d4-3c21a5665cec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: shutdown procedure required for beaglebone black ??

[tomlearman]

Can you use a remote bottom. Does this start-stop bottom come out on the 
terminal strip?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/488dca3c-bd9e-4531-9d16-7536a5e696c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BeagleBone Black Boot optimization

[Troy Weber]

That 4.14 kernal definitely improved the boot times compared to what I was 
seeing and what I posted 
here: https://github.com/RobertCNelson/boot-scripts/issues/10

However, I am still getting a boot time of close to a minute (~32 seconds 
for both *dev-mmcblk1p1.device* and *generic-board-startup.service*).

# systemd-analyze 
Startup finished in 21.569s (kernel) + 37.032s (userspace) = 58.602s

# systemd-analyze blame
 32.599s dev-mmcblk1p1.device
 31.957s generic-board-startup.service
  3.137s systemd-udev-trigger.service
  2.602s loadcpufreq.service
  2.090s networking.service
  1.638s ssh.service
  1.542s connman.service
  1.385s systemd-logind.service
  1.196s systemd-journald.service
  1.164s avahi-daemon.service
  1.158s udhcpd.service
   841ms dnsmasq.service
   833ms pppd-dns.service
   786ms bb-wl18xx-wlan0.service
   623ms cpufrequtils.service
   536ms systemd-timesyncd.service
   497ms rsyslog.service
   445ms wpa_supplicant.service
   416ms systemd-random-seed.service
   367ms systemd-udevd.service
   350ms kmod-static-nodes.service
   333ms systemd-modules-load.service
   314ms systemd-sysctl.service
   311ms systemd-user-sessions.service
   311ms hostapd.service
   304ms systemd-update-utmp.service
   303ms sys-kernel-debug.mount
   301ms sys-kernel-config.mount
   297ms systemd-remount-fs.service
   275ms systemd-tmpfiles-setup.service
   248ms systemd-journal-flush.service
   220ms media-sd.mount
   206ms systemd-tmpfiles-setup-dev.service
   191ms sys-fs-fuse-connections.mount
   185ms user@0.service

Can anything be done to really trim down the boot time to be not much more 
than the kernel boot time? And what does one sacrifice in doing so? A 30 
second boot would be great. This 60 boot isn't too bad, either, of course, 
thanks for your work on that kernel 4.14.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d2b8dbe7-0931-44c9-a482-0e1df52699bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Linux classes at Embedded World

[Jason Kridner]

If you are at Embedded World, see
https://www.embedded-world.eu/program.html and
search for "Introduction to Embedded Linux". First session is completely
full, but they've added at least one more.

You can also find folks from Texas Instruments, Octavo Systems, GHI
Electronics, Element14, Digi-Key, Mouser, Arrow and many more there this
week.

Details on this class...

Introduction to Embedded Linux / Theory and Practice Crash Course:
Description: This one day training class uses hands-on exercises combined
with instruction to illustrate some basic concepts of Embedded GNU/Linux.

Hands on sessions are performed with a toolchain/rootfs built by the freely
available Yocto Project, on an embedded board. This enables you to take the
course material home and work with it. The whole workshop is designed to
bring you quickly up to speed. The concepts and commands necessary to make
effective use of Embedded GNU/Linux are described through a combination of
theory and on-the-job training. Don't reinvent the wheel, but learn from an
experienced trainer and take home a working knowledge of Embedded GNU/Linux
and the ability to use it effectively in your own embedded development
project.

Intended audience: Project managers, software, hardware, development and
systems engineers, technicians and those interested in technology who want
to try to understand as quickly as possible how Embedded GNU/Linux works.

The trainer will bring laptops and technical equipment.

Since 1993, Robert Berger gathered practical and managerial experience in
software design and development for embedded systems with and without hard
real-time requirements. Since the beginning of the 21st century, he has
used GNU/Linux on desktop and server class machines, but mainly for
embedded practices (automotive, industrial control, robotics, telecoms,
consumer electronics, etc.). Robert regularly attends international events
such as "Embedded World", "Embedded Software Engineering Congress",
"Embedded Systems Conference", and "Embedded Linux Conference" as an expert
and lecturer. His speciality is mainly training, but also consulting (in
German or English) worldwide. Robert's expertise ranges from the smallest
real-time systems (FreeRTOS) to set-ups with multiple processors/cores and
embedded GNU/Linux (user-, kernel-space, device drivers, hardware
interfacing, debugging, multi-core, Yocto Project) with a focus on free and
open source software. Robert is a globe-trotter. He is CEO & Embedded
Software Specialist at Reliable Embedded Systems - Robert Berger e.U. which
is based in St. Barbara, Austria, and when not traveling, lives with his
family in Athens, Greece.

-- 
https://beagleboard.org/about

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPnGXwEyaCvJPTFgmXj%3DPXtjwm1C8%3DzensYf_K4%2B1719Eg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone Black boot from NAND

[QDmitry]

Hi there,
I'm playing with BBB black at the moment. Using the following 
article 
https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot
 
I got it work as described.

Now I have a custom board based on BBB with NAND installed ( 
MT29F4G16ABADAWP ). The only way to boot this board is to flash uboot image 
on it. I got NAND_Flashing_Tool CCS project for burning. And I'm in stuck 
with Uboot - how can I enable booting from NAND? What configuration option 
should I turn on?

Any help is highly appreciated as I'm a newbie with this low level stuff.

Thanks a lot in advance,
BR, Dmitry

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c723b837-a3a3-477a-8b4e-f7a320179c84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How handle interrupts in ARM from PRU

[jkorxado]

Hi guys,

I'm new in embedded systems and me English is not very good, but I will try.

I have a board like the beaglebone with buildroot system, and the board has 
a ARM main processor and 2 pru. 

I installed the remoteproc lib in the board for communicate the PRU -> ARM 
via interrupt.

I dont know and I dont find anything about how it possible to handle the 
interrupt in ARM processor that I have installed Qt IDE.

Anyone can help me?

Thanks and sorry for me English.

Jaime

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3c110fb5-f449-4c85-8b0b-192800d72c4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Log file from daemon.log

[Jiye Tang]

Hi,

My distribution is:

BeagleBoard.org Debian Image 2016-12-09

>From one of my units I am able to see the dhcp request from the usb0 like
this:

Feb 25 22:26:03 beaglebone dnsmasq-dhcp[689]: DHCPINFORM(usb0) 192.168.7.1
38:d2:69:57:cc:c2
Feb 25 22:26:03 beaglebone dnsmasq-dhcp[689]: DHCPACK(usb0) 192.168.7.1
38:d2:69:57:cc:c2 TJWill-VAIO
Feb 25 22:26:06 beaglebone dnsmasq-dhcp[689]: DHCPINFORM(usb0) 192.168.7.1
38:d2:69:57:cc:c2
Feb 25 22:26:06 beaglebone dnsmasq-dhcp[689]: DHCPACK(usb0) 192.168.7.1
38:d2:69:57:cc:c2 TJWill-VAIO
Feb 25 22:26:11 beaglebone dnsmasq-dhcp[689]: DHCPREQUEST(usb0) 192.168.7.1
38:d2:69:57:cc:c2
Feb 25 22:26:11 beaglebone dnsmasq-dhcp[689]: DHCPACK(usb0) 192.168.7.1
38:d2:69:57:cc:c2 TJWill-VAIO

Please also see the log files from the daemon.log for the one that usb0
fails to connect after 10 seconds:
Weird thing is that I don't see the dhcp request during the log,

Feb 26 14:29:03 WarrierTech-BetaTester-Location connmand[2943]: Remove
interface usb0 [ gadget ]
Feb 26 14:29:03 WarrierTech-BetaTester-Location connmand[2943]: usb0
{remove} index 3
Feb 26 14:29:03 WarrierTech-BetaTester-Location connmand[3030]: usb0
{create} index 3 type 1 
Feb 26 14:29:03 WarrierTech-BetaTester-Location connmand[3030]: usb0 {RX}
848 packets 79152 bytes
Feb 26 14:29:03 WarrierTech-BetaTester-Location connmand[3030]: usb0 {TX}
183 packets 50652 bytes
Feb 26 14:29:04 WarrierTech-BetaTester-Location connmand[3030]: usb0
{update} flags 69699 
Feb 26 14:29:04 WarrierTech-BetaTester-Location connmand[3030]: usb0
{newlink} index 3 address 38:D2:69:57:DD:16 mtu 1500
Feb 26 14:29:04 WarrierTech-BetaTester-Location connmand[3030]: usb0
{newlink} index 3 operstate 6 
Feb 26 14:29:04 WarrierTech-BetaTester-Location connmand[3030]: Ignoring
interface usb0 (filtered)
Feb 26 14:29:04 WarrierTech-BetaTester-Location connmand[3030]: Adding
interface usb0 [ gadget ]
Feb 26 14:29:04 WarrierTech-BetaTester-Location connmand[3030]: usb0 {add}
address 192.168.7.2/30 label usb0 family 2
Feb 26 14:29:04 WarrierTech-BetaTester-Location connmand[3030]: usb0 {add}
route 192.168.7.0 gw 0.0.0.0 scope 253 
Feb 26 14:29:49 WarrierTech-BetaTester-Location udhcpd[1035]: is interface
usb0 up and configured?: No such device
Feb 26 14:29:53 WarrierTech-BetaTester-Location connmand[902]: usb0
{create} index 3 type 1 
Feb 26 14:29:53 WarrierTech-BetaTester-Location connmand[902]: usb0
{update} flags 4098 
Feb 26 14:29:53 WarrierTech-BetaTester-Location connmand[902]: usb0
{newlink} index 3 address 38:D2:69:57:DD:16 mtu 1500
Feb 26 14:29:53 WarrierTech-BetaTester-Location connmand[902]: usb0
{newlink} index 3 operstate 2 
Feb 26 14:29:53 WarrierTech-BetaTester-Location connmand[902]: Ignoring
interface usb0 (filtered)
Feb 26 14:29:53 WarrierTech-BetaTester-Location connmand[902]: Adding
interface usb0 [ gadget ]
Feb 26 14:29:54 WarrierTech-BetaTester-Location connmand[902]: usb0 {add}
address 192.168.7.2/24 label usb0 family 2
Feb 26 14:29:54 WarrierTech-BetaTester-Location connmand[902]: usb0
{update} flags 69699 
Feb 26 14:29:54 WarrierTech-BetaTester-Location connmand[902]: usb0
{newlink} index 3 address 38:D2:69:57:DD:16 mtu 1500
Feb 26 14:29:54 WarrierTech-BetaTester-Location connmand[902]: usb0
{newlink} index 3 operstate 6 
Feb 26 14:29:54 WarrierTech-BetaTester-Location connmand[902]: Ignoring
interface usb0 (filtered)
Feb 26 14:29:54 WarrierTech-BetaTester-Location avahi-daemon[822]: Joining
mDNS multicast group on interface usb0.IPv4 with address 192.168.7.2.
Feb 26 14:29:54 WarrierTech-BetaTester-Location connmand[902]: usb0 {add}
route 192.168.7.0 gw 0.0.0.0 scope 253 
Feb 26 14:29:54 WarrierTech-BetaTester-Location avahi-daemon[822]: New
relevant interface usb0.IPv4 for mDNS.
Feb 26 14:29:54 WarrierTech-BetaTester-Location avahi-daemon[822]:
Registering new address record for 192.168.7.2 on usb0.IPv4.
Feb 26 14:29:54 WarrierTech-BetaTester-Location connmand[902]: usb0 {add}
route fe80:: gw :: scope 0 
Feb 26 14:29:54 WarrierTech-BetaTester-Location avahi-daemon[822]:
Withdrawing address record for 192.168.7.2 on usb0.
Feb 26 14:29:54 WarrierTech-BetaTester-Location avahi-daemon[822]: Leaving
mDNS multicast group on interface usb0.IPv4 with address 192.168.7.2.
Feb 26 14:29:54 WarrierTech-BetaTester-Location connmand[902]: usb0 {del}
address 192.168.7.2/24 label usb0
Feb 26 14:29:54 WarrierTech-BetaTester-Location connmand[902]: usb0 {del}
route 192.168.7.0 gw 0.0.0.0 scope 253 
Feb 26 14:29:54 WarrierTech-BetaTester-Location avahi-daemon[822]:
Interface usb0.IPv4 no longer relevant for mDNS.
Feb 26 14:29:54 WarrierTech-BetaTester-Location avahi-daemon[822]: Joining
mDNS multicast group on interface usb0.IPv4 with address 192.168.7.2.
Feb 26 14:29:54 WarrierTech-BetaTester-Location avahi-daemon[822]: New
relevant interface usb0.IPv4 for mDNS.
Feb 26 14:29:54 WarrierTech-BetaTester-Location avahi-daemon[822]:
Registering new address record for 192.168.7.2 on usb0.IPv4.
Feb 26 

[beagleboard] 8.6 IoT Devbian Image Issue

[Jiye Tang]

Hi,


Recently I downloaded the 8.6-IoT image from your website and after I flash
the image I am able to log in the console for the first 10 seconds over the
usb port then after that I was unable to log in any more.

I tried other Debian images and this always works. I only seen this issue
on the Debian 8.6-IoT image so far. Wonder if I can get some help from you.
Seems like there is no dhcp request on USB0 port.



Regards,
-- 

*Jiye Tang *
WarrierTech Inc.
Suite 400, 5880 Spring Garden Road, Halifax, NS, Canada B3H 1Y1
C: 1-902-999-8895 <(902)%20488-8940>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAESsYt%2BmKRNpQRzDmbJdSk1qCGV1MF_ykO5F4mQy_E%2BD4YeBQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PocketBeagle not booting issue

[Loader]

Hello all, 
 
I've been experimenting with the working PocketBeagle and possibly modified the 
uEnv.txt file using the Cloud9 IDE terminal. Then I tried to reboot the board 
with the shutdown –r now command. The board didn't reload successfully, and 
after rebooting manually only the power LED was on. 
 
Thinking that I could have corrupted the image, I then erased the SD-card with 
the diskpart and flashed the SD-card with Etcher once again. The image used is 
Debian 9.3 2018-01-28 4GB SD IoT. Again only the power LED is on, no other 
signs of life. The board is also not present in the Device Manager anymore if 
the SD-card is on the board. If the board is connected to the PC without the 
SD-card, it's still recognized in the Device Manager. 
 
The SD card is fine, because it's recognized as a Linux filesystem partition, 
and later I've also flashed the image to a new clean SD-card. 
 
If this is of any help, the uEnv.txt after reflashing contains the following 
lines (apart from the commented ones): 
uname_r=4.9.78-ti-r94 
enable_uboot_overlays=1 
enable_uboot_cape_universal=1 
cmdline=coherent_pool=1M net.ifnames=0 quiet 
 
How can the board be revived? 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a7f4a2a8-3d3c-4a9e-8db6-178ef695000e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Problem with PINMUX - WARNING: missing PINMUX driver

[evilwulfie]

the errors you are seeing is because the pins are not setup
pins get setup by using an overlay at boot time

verify the overlay you require is being loaded in /boot/uEnv.txt

as of any 4.x  kernel everything must be loaded at boot time from that file

the cape manager is not used


On 2/26/2018 6:51 AM, Konrad Russa wrote:
> Hi,
>
> I have changed kernel to 4.4 lts and there is no Error but still PRU
> issues are there:
>
> can't open: /sys/devices/platform/ocp/ocp:H18_pinmux/state
> Pinmux: No such file or directory
> can't open: /sys/devices/platform/ocp/ocp:C18_pinmux/state
> Pinmux: No such file or directory
> can't open: /sys/devices/platform/ocp/ocp:P9_22_pinmux/state
> Pinmux: No such file or directory
> can't open: /sys/devices/platform/ocp/ocp:P9_21_pinmux/state
> Pinmux: No such file or directory
> can't open: /sys/devices/platform/ocp/ocp:P9_26_pinmux/state
> Pinmux: No such file or directory
> can't open: /sys/devices/platform/ocp/ocp:P9_24_pinmux/state
> Pinmux: No such file or directory
> can't open: /sys/devices/platform/ocp/ocp:P9_30_pinmux/state
> Pinmux: No such file or directory
> can't open: /sys/devices/platform/ocp/ocp:P9_29_pinmux/state
> Pinmux: No such file or directory
> can't open: /sys/devices/platform/ocp/ocp:P9_31_pinmux/state
> Pinmux: No such file or directory
> WARNING: missing PINMUX driver
> You probbaly just need a newer kernel
>   FusedTaitBryan(deg) |   Accel XYZ (g)   |  Gyro XYZ (deg/s) |
>     7.1   -7.5    nan |  1.81  1.61  9.96 |  -0.3  -0.3   0.1 |
>
> Do you have any idea what should I check ? I appreciate any help.
>
> Cheers,
> Konrad
>
> 2018-02-26 8:30 GMT+01:00 Konrad Russa  >:
>
> not sure, before I have flashed board with newest debian, 
> then just installed libraries required to compile newest version
> of opencv, 
> then started to check cape capabilities and saw first issues.
>
>
>
> 2018-02-26 1:16 GMT+01:00 evilwulfie  >:
>
> Just a question. What led up to this issue ?
> normally things dont go south unless you do something
>
>
>
> On 2/25/2018 4:57 PM, Konrad Russa wrote:
>> Hi,
>>
>> seems there is something with omap ?
>> I dont know (yet) what it is :/
>>
>> [    0.472645] omap_hwmod: debugss: _wait_target_disable failed
>> [    0.573125] omap4_sram_init:Unable to allocate sram needed
>> to handle errata I688
>> [    0.573141] omap4_sram_init:Unable to get sram pool needed
>> to handle errata I688
>>
>>
>>
>> -- 
>> Pozdrawiam
>> Konrad Russa
>
>
>
>
> -- 
> Pozdrawiam
> Konrad Russa
>
>
>
>
> -- 
> Pozdrawiam
> Konrad Russa

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/19071e2b-b1f3-af6b-ea25-c01e6b3eee79%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] U-boot dtbo

[Alan Thomason]

Hi Wulf Man...Thanks very much for the response.  I tried your suggestion 
of putting the custom cape in the next line, but could not see a change in 
the dmesg.  It really seems like the /boot/uEnv.txt file is not being 
reference at all.  

Alan



On Sunday, February 25, 2018 at 9:07:31 PM UTC-5, Wulf Man wrote:
>
> I add my custom capes under ###Additional custom capes
>
> I have no problems that way unless i create them in my files
> they all load fine
>
> i dont see that cape in my bb.org-overlays/scr/arm directory
>
> Is that custom ?
>
>
> On 2/25/2018 6:47 PM, Alan Thomason wrote:
>
> Hello all... 
>
> I am trying to use a newer image than I have in the past: 
>  BeagleBoard.org Debian Image 2017-10-10
>
> I have flashed the eMMC and am able to boot from it with no microSD card 
> in place.
>
> I have been working for the last year with an older (2014) image and I 
> compile and load an overlay.using the capemgr (sudo sh -c "echo 
> DesiredOverlay > /sys/devices/platform/bone_capemgr/slots") method.  I 
> understand from other posts that this is no longer the preferred method, 
> and I need to use the new method.  I *think* I have done what the 
> following suggests:
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
>   starting at:  U-Boot /boot/uEnv.txt configuration
>
> But I can't use the same PRU processes as I used before.  I get an error 
> (Segmentation fault) that in the previous image would indicate that I had 
> not yet loaded the overlay.  I don't see anything in the dmesg output that 
> would indicate that the uboot/uEnv.txt had run at all.
>
> My questions:
> 1. Does it look like I am properly loading the overlay 
> (EBB-PRU-CNKSim-00A0.dtbo) in the uEnv.txt?
> 2. Shouldn't I be able to see this in the dmesg output?
> 3. Is there a possibility that the /boot/uEnv.txt is not being run?
> 4. Is there an  easy way to put tell-tales in the uEnv.txt file so that 
> you could easily see where in the file the process had gotten to?
>
> Thanks in advance,
>
> Alan
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/9fec54c7-a337-4764-a11e-4dd30d0faa34%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/24370be7-b6dc-47f7-942c-829f2fe9b296%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.