Re: [beagleboard] Power - shutdown

[William Hermans]

>
> *Very much agree with you - even though I don't want to use a battery, it
> seems more and more than a battery is a necessity for field use of the BBB,
> which would explain the existing connector.*
>

Having a battery still does not solve two other problems.


   - Does not solve situations when a powered halt occurs.
   - Does not solve situations where USB is required.


A "powered halt" is something akin to issuing shutdown now -h while there
is still power coming in through the barrel jack, USB, or battery. I
suppose while coming in over the header too, but I've not tested this.
Anyway, when the board is "local" this is easily fixed by pressing the
reset button on the board. Or, sometimes removing power - completely. When
remote however . . . this proves to be a serious problem, which is only,
and currently solvable by using an external device to "press" the button
for you. A "smart watchdog" of sorts.

 As for the USB, only a power cycle will solve this situation. When powered
by battery only and the input voltage is less than 5V. You lose the USB in
software, and it will not come back until at least a reboot occurs. In
situations when the system must stay up, a UPS may make the most sense.

Then to be 100% clear. There is no battery connector. There are 4 test
points, were soldering 4 pins can make a connector possible.

Other situations where the power goes away, and comes back quickly. Or
where power comes back, and goes away quickly are problems too. Which can
easily be solved as well . . .

On Mon, May 2, 2016 at 4:29 PM, Robert Nelson 
wrote:

>
>
> On Mon, May 2, 2016 at 6:19 PM, William Hermans  wrote:
>
>> Robert has had 1 or more Beagleboard's running a read only file system
>> since . . . What Robert ? 2011 ? But you can search this group, and find
>> him talking about them in a few different posts.
>>
>
> If you install an image the old way:
>
> http://elinux.org/BeagleBoardDebian#Debian_.28jessie.29
>
> via "setup_sdcard.sh" there is a "--ro" flag..
>
> It might still work...
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgqCu8EaqnweV50NR5hgh7MzjOpArPoaJQSMh1H4gbHDg%40mail.gmail.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/CALHSORozfH%3DhOBU8kEXh-92N5jHwiD6_LMtfKBZVo3q2FcLn2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] nodejs

[Robert Nelson]

On Mon, May 2, 2016 at 9:56 PM, evilwulfie  wrote:

> I installed the nodejs package and noticed that on the command line
>
> i needed to use nodejs not the standard node command to invoke things
>
> i created a symlink so that nodejs pointed to node and all is well
>
> just wanted to point out the discrepancy.
>

In debian this package is "nodejs-legacy"

https://packages.debian.org/sid/nodejs-legacy

The answer to why: =

https://lists.debian.org/debian-devel-announce/2012/07/msg2.html

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

[beagleboard] nodejs

[evilwulfie]

I installed the nodejs package and noticed that on the command line

i needed to use nodejs not the standard node command to invoke things

i created a symlink so that nodejs pointed to node and all is well

just wanted to point out the discrepancy.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

-- 
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/39cd9c1f-a587-990b-6583-4a41f031193c%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Custom Image advertising itself as Drive instead of USB drive

[Virendra]

Hi,

I have an issue with the current custom image(kernel_version=4.1.20) where 
the image advertises itself as a disk image. I didn't have this issue in 
the previous version of image(3.8.13-bone74.2). The previous version of 
image will present itself as a USB drive.

The 4.1.20 Image advertises itself as a disk, and when I plug into my Linux 
RedHat host, the /boot partition mounts, and a window pops open on my Linux 
host.Instead, it should present itself as a USB drive as done in previous 
image 3.8.13-bone74.2. My observations below are plugging the same Beagle 
board Black in the the same Linux host using the same bus powered USB port 
on the Linux host.

here is what I see on my Linux machine:
[root@cva-mp104 ~]# uname -a
Linux cva-mp104 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 
x86_64 x86_64 x86_64 GNU/Linux

*With my Current image(**4.1.20) - There is an issue:*

 my BeagleBoard Black plugged in:[root@cva-mp104 tmp]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 003: ID 0461:4dfb Primax Electronics, Ltd 
Bus 002 Device 004: ID 03f0:0024 Hewlett-Packard KU-0316 Keyboard
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 067: ID 1d6b:0104 Linux Foundation Multifunction Composite 
Gadget
 
 
 
*With my previous image(**3.8.13-bone74.2) - There is no issue:*
 
root@beaglebone:~# uname -a
Linux beaglebone 3.8.13-bone74.2 #3 SMP Wed Dec 9 16:31:22 CLT 2015 armv7l 
GNU/Linux

here is what I see (Notice the "NetChip technology" ... this work great for 
me to ssh in over USB:
[user@cva-mp104 part_table]$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 003: ID 0461:4dfb Primax Electronics, Ltd 
Bus 002 Device 004: ID 03f0:0024 Hewlett-Packard KU-0316 Keyboard
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 068: ID 048d:1336 Integrated Technology Express, Inc. SD/MMC 
Cardreader
Bus 003 Device 035: ID 0525:a4a2 Netchip Technology, Inc. Linux-USB 
Ethernet/RNDIS Gadget


Could you please help how to resolve this issue so that the image 4.1.20 
present itself as a USB drive and not advertise itself as a disk.

Thanks,
Veera

-- 
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/24781d0d-d33e-438c-9e29-9344baeff167%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: [beagle-alpha] debian testing: 2016-05-01

[William Hermans]

By "installling" I mean I'll be compiling my own Nodejs 4.x from source,
and creating a package.

On Mon, May 2, 2016 at 5:48 PM, William Hermans  wrote:

> Robert,
>
> Nodejs 4.x is possible on these images yet ?
>
> I was considering getting a Jessie image and backing out of systemd, then
> attempting to install Nodejs 4.x lts on it.
>  However if these images are not yet capable of Nodejs 4.x . . . then
> moving onward to a jessie image does not make so much sense for us.
>
> On Mon, May 2, 2016 at 2:37 PM, Robert Nelson 
> wrote:
>
>>
>>
>> On Mon, May 2, 2016 at 4:00 PM, Robert Nelson 
>> wrote:
>>
>>>
>>>
>>> On Mon, May 2, 2016 at 3:11 PM, Jason Kridner 
>>> wrote:
>>>


 On Mon, May 2, 2016 at 10:50 AM Robert Nelson 
 wrote:

> Howdy!
>
> So there's a little something new in this week's snapshot:
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01
>
> We've now switched from v4.1.x-ti to v4.4.x-ti by default.
>

 With 4.4, should we be enabling -rt?

>>>
>>> Good point, we were going to try that again, just did:
>>>
>>>25  cd /opt/scripts/tools/
>>>26  git pull
>>>27  sudo ./update_kernel.sh --ti-rt-channel --lts-4_4
>>>
>>> debian@beaglebone:~$ uname -r
>>> 4.4.8-ti-rt-r22
>>>
>>> So far, usb networking/flash/serial seem to work fine on my linux box..
>>> (with 4.1.x-rt serial would fail).. I'll test windows 10 in a bit..
>>>
>>> NM... it just hardlocked while typing this email... back to non-rt and
>>> more testing. ;)
>>>
>>>


>
> hostap/wpasuppliant saw a major upgrade: 2.3 -> 2.5
>

 Does this image include the WL183x patches from TI?

>>>
>>>
>>> Nope, not yet..  I'm watching this tree for patches:
>>>
>>> http://git.ti.com/gitweb/?p=wilink8-wlan/hostap.git;a=summary
>>>
>>> R8.7_RC14
>>> 
>>>  just
>>> showed up a little bit ago..
>>>
>>>
>>>


>
> Board specific documentation:
>
> BBW/BBB = BeagleBoard.org documentation over usb flash
>
> BBG = seeedstudio.com documentation over usb flash
>
> bonescript 0.5.0-beta with more fixes
>

 I'm assuming beta4. I'll try to get the fix in if using the old cape
 manager to continue using the old functions. All should be working better
 for the newer kernels.

>>>
>>> Correct beta4, but i need to fix
>>>
>>> [   22.276862] bone_capemgr bone_capemgr: part_number 'univ-emmc',
>>> version 'N/A'
>>> [   22.276896] bone_capemgr bone_capemgr: slot #4: override
>>> [   22.276911] bone_capemgr bone_capemgr: Using override eeprom data at
>>> slot 4
>>> [   22.276927] bone_capemgr bone_capemgr: slot #4: 'Override Board
>>> Name,00A0,Override Manuf,univ-emmc'
>>> [   22.464473] of_resolve_phandles: Could not find symbol 'pruss'
>>> [   22.470418] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree
>>>
>>> and stick a pruss node in the default dtb to make things happy for
>>> cape-universal...
>>>
>>
>> r23 fixes this with a quick hack.. (remoteproc_pruss hasn't been merged
>> in ti's v4.4.x as of today yet..) SO the cape-universal overlay will load..
>>
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYiArySkARUbwFkqFmoQcs-vPgnu6beoJYDLKCSEq_vGjg%40mail.gmail.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/CALHSORq%2BGLvdyQp8f55jUwXj2B7ZbwOKr%2BW_dbXu3jo7wpvv%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: [beagle-alpha] debian testing: 2016-05-01

[William Hermans]

Robert,

Nodejs 4.x is possible on these images yet ?

I was considering getting a Jessie image and backing out of systemd, then
attempting to install Nodejs 4.x lts on it.
 However if these images are not yet capable of Nodejs 4.x . . . then
moving onward to a jessie image does not make so much sense for us.

On Mon, May 2, 2016 at 2:37 PM, Robert Nelson 
wrote:

>
>
> On Mon, May 2, 2016 at 4:00 PM, Robert Nelson 
> wrote:
>
>>
>>
>> On Mon, May 2, 2016 at 3:11 PM, Jason Kridner  wrote:
>>
>>>
>>>
>>> On Mon, May 2, 2016 at 10:50 AM Robert Nelson 
>>> wrote:
>>>
 Howdy!

 So there's a little something new in this week's snapshot:

 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01

 We've now switched from v4.1.x-ti to v4.4.x-ti by default.

>>>
>>> With 4.4, should we be enabling -rt?
>>>
>>
>> Good point, we were going to try that again, just did:
>>
>>25  cd /opt/scripts/tools/
>>26  git pull
>>27  sudo ./update_kernel.sh --ti-rt-channel --lts-4_4
>>
>> debian@beaglebone:~$ uname -r
>> 4.4.8-ti-rt-r22
>>
>> So far, usb networking/flash/serial seem to work fine on my linux box..
>> (with 4.1.x-rt serial would fail).. I'll test windows 10 in a bit..
>>
>> NM... it just hardlocked while typing this email... back to non-rt and
>> more testing. ;)
>>
>>
>>>
>>>

 hostap/wpasuppliant saw a major upgrade: 2.3 -> 2.5

>>>
>>> Does this image include the WL183x patches from TI?
>>>
>>
>>
>> Nope, not yet..  I'm watching this tree for patches:
>>
>> http://git.ti.com/gitweb/?p=wilink8-wlan/hostap.git;a=summary
>>
>> R8.7_RC14
>> 
>>  just
>> showed up a little bit ago..
>>
>>
>>
>>>
>>>

 Board specific documentation:

 BBW/BBB = BeagleBoard.org documentation over usb flash

 BBG = seeedstudio.com documentation over usb flash

 bonescript 0.5.0-beta with more fixes

>>>
>>> I'm assuming beta4. I'll try to get the fix in if using the old cape
>>> manager to continue using the old functions. All should be working better
>>> for the newer kernels.
>>>
>>
>> Correct beta4, but i need to fix
>>
>> [   22.276862] bone_capemgr bone_capemgr: part_number 'univ-emmc',
>> version 'N/A'
>> [   22.276896] bone_capemgr bone_capemgr: slot #4: override
>> [   22.276911] bone_capemgr bone_capemgr: Using override eeprom data at
>> slot 4
>> [   22.276927] bone_capemgr bone_capemgr: slot #4: 'Override Board
>> Name,00A0,Override Manuf,univ-emmc'
>> [   22.464473] of_resolve_phandles: Could not find symbol 'pruss'
>> [   22.470418] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree
>>
>> and stick a pruss node in the default dtb to make things happy for
>> cape-universal...
>>
>
> r23 fixes this with a quick hack.. (remoteproc_pruss hasn't been merged in
> ti's v4.4.x as of today yet..) SO the cape-universal overlay will load..
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYiArySkARUbwFkqFmoQcs-vPgnu6beoJYDLKCSEq_vGjg%40mail.gmail.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/CALHSORrkMabNd5MKvuZ8V9691TTJAz1-TiEeyqy7XvKjguy4VA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble enabling DCAN1 on BeagleBone, think I'm close but missing something.

[William Hermans]

You're providing far too much information, and not enough of the right
information. It would be good to know the output of the following commands.

cat /sys/devices/platform/bone_capemgr/slots
ifconfig can0

Additionally, I know nothing of the cape you mention, and knowing your
circuit layout would be good too, but not really necessary. Many seem to
have had this same, or similar issues, which I'll assume is related to
improper CANBUS termination. But since no one has bothered to come back on
and follow up . . . who really knows ? I do know that using the Logicsupply
CAN cape works. We have one, and I've dumped loads of data off a "local"
industrial CAN network.

On Mon, May 2, 2016 at 12:50 PM,  wrote:

> Hi Folks,
>
> I am easily able to receive CAN traffic with my Peak USB-CAN interface on
> my linux workstation.  I know our device is producing regular updates at
> 25 and it dumps find using candump.
>
> For a couple days I have been trying (without success) to duplicate the
> behavior on my Element Rev B6 Beaglebone.  I've read many posts and have
> worked bast a bunch of issues but still get no can traffic.
>
> The results are the same with a WaveShare CAN Cape or a discrete NXP
> TJA1051 High-speed CAN transceiver that I have connected on a breadboard.
> If I hook a scope to the input RX signal I can see the external CAN traffic
> but nothing gets through.
>
> I did modify ~/bb.org-overlays/src/arm/cape-universaln-00A0.dts to remove
> references to pins P9_24 and P9_26 (UART1 RX/TX)
>
> For clarity's sake here is the script that I run after rebooting the
> Beaglbone.
>
> set -x
> echo "# make sure, I'm running as root, unmolested
> bone-debian-8.3-lxqt-4gb-armhf-2016-01-24-4gb.img image"
> id
> uname -a
>
> echo "# look, can pin muxing for P9_24 and P9_26 are at default (GPIO,
> mode 7)"
> devmem2 0x44E10980 w
> devmem2 0x44E10984 w
>
> echo "# cat my overlay File, has been built/installed/rebooted
> successfully"
> cat /hone/debian/bb.org-overlays/src/arm/BB-CAN1-00A0.dts
>
> echo "# install my overlay to setup the CAN pins"
> sh -c "echo 'BB-CAN1' > /sys/devices/platform/bone_capemgr/slots"
>
> echo "# see that the overlay was installed and make sure pins went to
> mode 2"
> cat /sys/devices/platform/bone_capemgr/slots
> devmem2 0x44E10980 w
> devmem2 0x44E10984 w
>
> echo "#load the can drivers"
> modprobe can
> modprobe can-dev
> modprobe can-raw
>
> echo "# show what's loaded"
> lsmod
>
> echo "# fire up the interface"
> ip link set can0 type can bitrate 25 triple-sampling on
> ip link set can0 up
>
> echo "# see that we're up"
> ifconfig can0
>
> echo "#Shoud receive can data, same as my linux workstation..."
> candump can0
>
>
> Here is the output from the script..
>
> debian@beaglebone:~$ sudo ./canSetup.sh
> + echo # make sure, I'm running as root, unmolested
> bone-debian-8.3-lxqt-4gb-armhf-2016-01-24-4gb.img image
> # make sure, I'm running as root, unmolested
> bone-debian-8.3-lxqt-4gb-armhf-2016-01-24-4gb.img image
> + id
> uid=0(root) gid=0(root) groups=0(root)
> + uname -a
> Linux beaglebone 4.1.15-ti-rt-r43 #1 SMP PREEMPT RT Thu Jan 21 20:13:58
> UTC 2016 armv7l GNU/Linux
> + echo # look, can pins P9_24 and P9_26 are at default (GPIO, mode 7)
> # look, can pins P9_24 and P9_26 are at default (GPIO, mode 7)
> + devmem2 0x44E10980 w
> /dev/mem opened.
> Memory mapped at address 0xb6f93000.
> Value at address 0x44E10980 (0xb6f93980): 0x37
> + devmem2 0x44E10984 w
> /dev/mem opened.
> Memory mapped at address 0xb6f9b000.
> Value at address 0x44E10984 (0xb6f9b984): 0x37
> + echo # cat my overlay File, has been built/installed/rebooted
> successfully
> # cat my overlay File, has been built/installed/rebooted successfully
> + cat /home/debian/bb.org-overlays/src/arm/BB-CAN1-00A0.dts
> /*
>  * Copyright (C) 2015 Robert Nelson 
>  *
>  * Virtual cape for CAN1 on connector pins P9.24 P9.26
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  */
> /dts-v1/;
> /plugin/;
>
> #include 
> #include 
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black",
> "ti,beaglebone-green";
>
> /* identification */
> part-number = "BB-CAN1";
> version = "00A0";
>
> /* state the resources this cape uses */
> exclusive-use =
> /* the pin header uses */
> "P9.24",/* can1_rx */
> "P9.26",/* can1_tx */
> /* the hardware ip uses */
> "dcan1";
>
> fragment@0 {
> target = <_pinmux>;
> __overlay__ {
> bb_dcan1_pins: pinmux_dcan1_pins {
> pinctrl-single,pins = <
> BONE_P9_24 (SLEWCTRL_FAST | PIN_INPUT_PULLUP |
> MUX_MODE2) /* uart1_txd.d_can1_rx */
> BONE_P9_26 (SLEWCTRL_FAST | PIN_OUTPUT_PULLUP |
> MUX_MODE2) /* uart1_rxd.d_can1_tx */
> >;
> 

Re: [beagleboard] Power - shutdown

[Robert Nelson]

On Mon, May 2, 2016 at 6:19 PM, William Hermans  wrote:

> Robert has had 1 or more Beagleboard's running a read only file system
> since . . . What Robert ? 2011 ? But you can search this group, and find
> him talking about them in a few different posts.
>

If you install an image the old way:

http://elinux.org/BeagleBoardDebian#Debian_.28jessie.29

via "setup_sdcard.sh" there is a "--ro" flag..

It might still work...

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

Re: [beagleboard] Setting UART speed on BBB Rev C

[William Hermans]

https://groups.google.com/forum/#!searchin/beagleboard/Problemas$20para$20comunicar$20com$20o$20Baud$20Rate$205760/beagleboard/GC0rKe6rM0g/13c1ngXF7owJ

Read the posts by Peter Hurley

On Mon, May 2, 2016 at 1:24 PM, Pierce Nichols 
wrote:

> Hi all,
>
> I posted this to the Beaglebone list as well, but it seems a bit dead
> so I'm reposting here.
>
> I would like to find a way to set the speed of the UARTs to something
> other than the standard speeds offered by termios.
>
> I'm running a BBB Rev C with Debian 8.3, stock kernel from
> beaglebone.org. I'm using the universal cape and config-pin for setup
> (because it works well enough, so far). I currently have it working
> with a serial speed of 115.2 kbps, but the listener can't handle any
> of the standard termios speeds above that. It can handle 250, 500, or
> 1000 kbps, however. How can I set the BBB UARTs to operate at one of
> those speeds?
>
> -p
>
> PS -- I've considered shifting over to SPI on the next hardware rev,
> but that will be a little bit and I'd like more speed now.
>
> --
> Pierce Nichols
> Principal Engineer
> Logos Electromechanical, LLC
>
> --
> 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/CAENK0Pz5t2FyDi-b42krTfZayFEUB_vBV%2BqqiKKFtz0NKFK0TQ%40mail.gmail.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/CALHSORr2KC9Aw0wzC_%2BsrBb9pGdZ-HYR%3DyzwBHtW6HWgXW0Pxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Power - shutdown

[William Hermans]

Robert has had 1 or more Beagleboard's running a read only file system
since . . . What Robert ? 2011 ? But you can search this group, and find
him talking about them in a few different posts.

On Mon, May 2, 2016 at 12:09 PM, Yiannis Papelis  wrote:

> Mike,
>
> Thanks for the suggestion, this seems like a viable alternative.
>
>
> On Monday, May 2, 2016 at 3:02:57 PM UTC-4, mjc wrote:
>>
>> On 05/02/2016 02:54 PM, Yiannis Papelis wrote:
>> > Very much agree with you - even though I don't want to use a battery,
>> it
>> > seems more and more than a battery is a necessity for field use of the
>> > BBB, which would explain the existing connector.
>>
>> In my work, the solution was to use a read-only filesystem with a tmpfs
>> overlay. I mount the boot and root partitions read-only, and configure
>> /etc/sysconfig/readonly-root with READONLY=yes and TEMPORARY_STATE=yes.
>> (This system runs Fedora.)
>>
>> Permanent file writes are not frequently needed, but the filesystems can
>> be temporarily re-mounted as read/write when they are required.
>>
>> Also, I use a Swissbit SD card, which is more robust (and expensive)
>> than normal SD cards, because it contains additional power-down
>> protection.
>>
>> I haven't experienced any filesystem corruption since switching to this
>> approach.
>>
>> I did use supercaps as pseudo-battery-backups for a while - the program
>> would switch the filesystem to readonly as soon as a powerfail circuit
>> was tripped - but the readonly+overlay approach is simpler and more
>> robust in practice.
>>
>> - Mike
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/184788e1-295e-46d0-a5ac-a168a061eeb2%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/CALHSORrg59kV-CzFvjcJ92fdsnmZM82tLBJ-FPhhrPgin7tZ-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Power - shutdown

[William Hermans]

>
> *As someone already posted, this is a bit more complicated than that, but
> I get the idea.*
>

I did not see anyone other than you, I, and Gerald post on your discussion
here. But I do not get every post to this group..

But, sure . . . it is not as simple as that because while the board is
still being powered, a shutdown now -h will keep one from being able to
reset the board remotely. This applies to being powered by battery too.

In this case, where the board is being powered by a battery, super cap, or
whatever. You need an external "device" to break VIN to the board. Or this
would be a perfect example of why having a hard reset tied to a test point,
or header pin would be beneficial. But we do not have this feature, so
externally is a must.

As for the software. Everything is already in place except for one small
piece. A userspace app that monitors the systems interrupts, particularly
for the PMIC. Something similar to acpid( a daemon ), or whatever you
prefer.

william@beaglebone:~$ cat /proc/interrupts
   CPU0
 16:2671562  INTC  68 Level gp_timer

. . .

179: 20  INTC   7 Level tps65217
Err:  0

william@beaglebone:~$ cat /proc/irq/179/spurious
count 0
unhandled 0
last_unhandled 0 ms


Is pretty straight forward, and obvious. Things get a bit more complex, and
interesting where the external solution is concerned. It is solvable
though, we have solved it.

On Mon, May 2, 2016 at 11:55 AM, Yiannis Papelis  wrote:

> As someone already posted, this is a bit more complicated than that, but I
> get the idea.
>
> On Monday, May 2, 2016 at 2:09:44 PM UTC-4, William Hermans wrote:
>>
>> *Use a super capacitor.*
>>>
>>
>> Ok, a little abstract . . .
>>
>> Use a super capacitor, and if using a console image . . .  sudo apt-get
>> install acpid
>>
>> Then the board will automatically shutdown when 5V input goes missing.
>> I'd make sure you pick a super cap that can sustain the beaglebone for ~30
>> seconds, even if not needed. Just in case. Typically though, here, we see
>> that the board shuts down within 5 seconds or so. Maybe slightly longer.
>>
>> On Mon, May 2, 2016 at 10:47 AM, William Hermans 
>> wrote:
>>
>>> *I have been building embedded systems for a while now and I am
 considering using the beaglebone (BBB) for an upcoming project, but I am
 confused by everything I read regarding the shutdown requirements. As an
 embedded system the only way to turn it off is to simply shutdown the power
 with a switch, yet my preliminary research indicates that this is a no-no
 as it may damage the BBB and/or corrupt the file system.  I also read a lot
 of comments regarding voltage on the pins after a shutdown; in my case,
 very likely there will be a CAT5 cable with live activity connected even
 after power down; assume the magnetics should protect the BBB, but just
 checking.*

>>>
>>> This is true of any system running an OS that is not red only. If you
>>> unceremoniously yank the power, you're asking for trouble.
>>>
>>> *I have used quite a few micro controllers and various self-standing
 systems, but am fairly new to the BBB - still mostly reading about it.  Am
 I missing something?  How can a device meant to be used in embedded systems
 not be tolerant of power loss and be so finicky about power?*

>>>
>>> It sounds like you're missing a lot. It sounds like you've had a lot of
>>> experience with small micros, that run bare metal, but have have no, or
>>> limited experience with using an embedded OS.
>>>
>>> Then if you stop and think of the cost of this board, and what the goal
>>> of beagleboard.org was when the board was created. Perhaps then it
>>> become clear as to how / why we're where we are in this context. You can
>>> fix all of this yourself, using external hardware, and custom software.
>>>

 *By the way, I can see there is a battery backup circuit but I do not
 want to use a lithium battery for safety/temperature/cost reasons.  Using a
 large capacitor also seems tricky as the shutdown may take a few seconds so
 I don't see how that will work.*

 *Any suggestions would be greatly appreciated.*
>>>
>>>
>>> Use a super capacitor.
>>>
>>>
>>>
>>> On Mon, May 2, 2016 at 8:39 AM, Gerald Coley 
>>> wrote:
>>>


 On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis 
 wrote:

> I have been building embedded systems for a while now and I am
> considering using the beaglebone (BBB) for an upcoming project, but I am
> confused by everything I read regarding the shutdown requirements. As an
> embedded system the only way to turn it off is to simply shutdown the 
> power
> with a switch, yet my preliminary research indicates that this is a no-no
> as it may damage the BBB and/or corrupt the file system.  I also read a 
> lot
> of comments 

[beagleboard] Re: [beagle-alpha] debian testing: 2016-05-01

[Robert Nelson]

On Mon, May 2, 2016 at 4:00 PM, Robert Nelson 
wrote:

>
>
> On Mon, May 2, 2016 at 3:11 PM, Jason Kridner  wrote:
>
>>
>>
>> On Mon, May 2, 2016 at 10:50 AM Robert Nelson 
>> wrote:
>>
>>> Howdy!
>>>
>>> So there's a little something new in this week's snapshot:
>>>
>>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01
>>>
>>> We've now switched from v4.1.x-ti to v4.4.x-ti by default.
>>>
>>
>> With 4.4, should we be enabling -rt?
>>
>
> Good point, we were going to try that again, just did:
>
>25  cd /opt/scripts/tools/
>26  git pull
>27  sudo ./update_kernel.sh --ti-rt-channel --lts-4_4
>
> debian@beaglebone:~$ uname -r
> 4.4.8-ti-rt-r22
>
> So far, usb networking/flash/serial seem to work fine on my linux box..
> (with 4.1.x-rt serial would fail).. I'll test windows 10 in a bit..
>
> NM... it just hardlocked while typing this email... back to non-rt and
> more testing. ;)
>
>
>>
>>
>>>
>>> hostap/wpasuppliant saw a major upgrade: 2.3 -> 2.5
>>>
>>
>> Does this image include the WL183x patches from TI?
>>
>
>
> Nope, not yet..  I'm watching this tree for patches:
>
> http://git.ti.com/gitweb/?p=wilink8-wlan/hostap.git;a=summary
>
> R8.7_RC14
> 
>  just
> showed up a little bit ago..
>
>
>
>>
>>
>>>
>>> Board specific documentation:
>>>
>>> BBW/BBB = BeagleBoard.org documentation over usb flash
>>>
>>> BBG = seeedstudio.com documentation over usb flash
>>>
>>> bonescript 0.5.0-beta with more fixes
>>>
>>
>> I'm assuming beta4. I'll try to get the fix in if using the old cape
>> manager to continue using the old functions. All should be working better
>> for the newer kernels.
>>
>
> Correct beta4, but i need to fix
>
> [   22.276862] bone_capemgr bone_capemgr: part_number 'univ-emmc', version
> 'N/A'
> [   22.276896] bone_capemgr bone_capemgr: slot #4: override
> [   22.276911] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 4
> [   22.276927] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,univ-emmc'
> [   22.464473] of_resolve_phandles: Could not find symbol 'pruss'
> [   22.470418] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree
>
> and stick a pruss node in the default dtb to make things happy for
> cape-universal...
>

r23 fixes this with a quick hack.. (remoteproc_pruss hasn't been merged in
ti's v4.4.x as of today yet..) SO the cape-universal overlay will load..

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

[beagleboard] Re: CCCCCCC's Debug serial port output on unsuccessful boot

[CEinTX]

I have seen this too.
It is as Gerald says. Your cape is loading one or more of the boot pins.
I did a cape - even though all the connections were high impedance inputs,
it was still enough to twitch the boot pins. Anyway, I ended up adjusting a 
couple
of the pullup  resistors to adjust for it on the pins I was using - changed 
from 100k to
33k. Only had to do this for the pullups - so apparently stealing even a 
little from the
33uA max source was enough to impact the boot read of the pins.
Hope that helps.

GL
Matt

On Monday, May 2, 2016 at 3:43:34 PM UTC-5, Matt99eo wrote:
>
> Working with a BBB that has a custom hardware cape on it.
>
> Sometimes I get an unsuccessful boot out of it where when connected to the 
> serial debug part I see the letter C printed indefinitely.
>
> I'd say 90% of the boot attempts work (serial debug looks normal) and 10% 
> I get the infinite C printout and no successful boot.  
>
>
> Any ideas?
>

-- 
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/a8acb994-f7cb-4c2f-a421-4265a2ccc9db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] debian testing: 2016-05-01

[Robert Nelson]

On Mon, May 2, 2016 at 3:50 PM, Rick Mann  wrote:

>
> > On May 2, 2016, at 13:48 , Robert Nelson 
> wrote:
> >
> >
> >
> > On Mon, May 2, 2016 at 3:17 PM, Rick Mann  wrote:
> >
> >> Yeah, sorry. By PRUSS I meant uio_pruss. I depend on a third-party lib
> that uses that and isn't like to be updated any time soon. I don't have
> time to learn how to update it right now, given all the other things I have
> to finish on this project.
> >
> > Hi Rick,
> >
> > by default v4.4.x-ti  (and the rt) will use remoteproc_pruss...
> >
> > For uio_pruss:
> >
> > cd /opt/scripts/tools/
> > git pull
> > sudo ./update_kernel.sh 
> >
> > Mainline (4.1.x lts)[edit]
> > 4.1.x BeagleBone/BeagleBone Black
> > --bone-kernel --lts-4_1
> >
> > 4.1.x BeagleBone/BeagleBone Black + RT
> > --bone-rt-kernel --lts-4_1
> >
> > Mainline (4.4.x lts)[edit]
> > 4.4.x BeagleBone/BeagleBone Black
> > --bone-kernel --lts-4_4
> >
> > 4.4.x BeagleBone/BeagleBone Black + RT
> > --bone-rt-kernel --lts-4_4
>
> Thanks, Robert. Is that better than just apt-getting a particular kernel?
> I guess it's a bit easier, and always pulls down the latest?
>

Eh, it's the same, as it also calls apt.. It just looks at these references
for the latest of each branch:

https://rcn-ee.net/repos/latest/jessie-armhf/

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhn-5SAVPhB8%2B6CqZ_ptJVCH1_YwtOgzet0-r8P4%2Bw%3DAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beagle-alpha] debian testing: 2016-05-01

[Robert Nelson]

On Mon, May 2, 2016 at 3:11 PM, Jason Kridner  wrote:

>
>
> On Mon, May 2, 2016 at 10:50 AM Robert Nelson 
> wrote:
>
>> Howdy!
>>
>> So there's a little something new in this week's snapshot:
>>
>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01
>>
>> We've now switched from v4.1.x-ti to v4.4.x-ti by default.
>>
>
> With 4.4, should we be enabling -rt?
>

Good point, we were going to try that again, just did:

   25  cd /opt/scripts/tools/
   26  git pull
   27  sudo ./update_kernel.sh --ti-rt-channel --lts-4_4

debian@beaglebone:~$ uname -r
4.4.8-ti-rt-r22

So far, usb networking/flash/serial seem to work fine on my linux box..
(with 4.1.x-rt serial would fail).. I'll test windows 10 in a bit..

NM... it just hardlocked while typing this email... back to non-rt and more
testing. ;)


>
>
>>
>> hostap/wpasuppliant saw a major upgrade: 2.3 -> 2.5
>>
>
> Does this image include the WL183x patches from TI?
>


Nope, not yet..  I'm watching this tree for patches:

http://git.ti.com/gitweb/?p=wilink8-wlan/hostap.git;a=summary

R8.7_RC14

just
showed up a little bit ago..



>
>
>>
>> Board specific documentation:
>>
>> BBW/BBB = BeagleBoard.org documentation over usb flash
>>
>> BBG = seeedstudio.com documentation over usb flash
>>
>> bonescript 0.5.0-beta with more fixes
>>
>
> I'm assuming beta4. I'll try to get the fix in if using the old cape
> manager to continue using the old functions. All should be working better
> for the newer kernels.
>

Correct beta4, but i need to fix

[   22.276862] bone_capemgr bone_capemgr: part_number 'univ-emmc', version
'N/A'
[   22.276896] bone_capemgr bone_capemgr: slot #4: override
[   22.276911] bone_capemgr bone_capemgr: Using override eeprom data at
slot 4
[   22.276927] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,univ-emmc'
[   22.464473] of_resolve_phandles: Could not find symbol 'pruss'
[   22.470418] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree

and stick a pruss node in the default dtb to make things happy for
cape-universal...



>
>
>>
>> nodejs v0.12.x
>>
>> Wireless AP by default:
>>
>> SSID: BeagleBone (or) BeagleBone-WXYZ
>>
>
> When would you not have the -WXYZ?
>

On initial first bootup.  Connman is so fast, wifi is already up before our
boot script has time to generate the ssh key's..  After our key's are
generated the ssid get's changed..

And on the x15, when you stick a usb wifi adapter is shows "BeagleBone".. ;)



>
>
>> PASS: BeagleBone
>>
>
> Can you summarize connman vs. other configs for the various network
> connections?
>

Connman is used by default for:

eth0/wlan0

/etc/network/interfaces is ignored except for the the usb0 values which are
used by the boot script to setup the usb0 network...

*Connman could be used for usb0, but there is no way to reserve
"192.168.7.2"...

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

Re: [beagleboard] 1-24-16 Debian 8.3 Jessie -- not working

[Robert Nelson]

On Mon, May 2, 2016 at 3:01 PM,  wrote:

>
> Hello, I am a novice when it comes to using the BBB. I have a revC and I
> have just started to play around with it. I have just updated the board to
> the latest image from the beagleboard.org/latest-images web site, which
> is the Debian 8.3 "Jessie" build from 24-Jan, and I cannot get anything to
> work via Bonescript on this build.
>

Grab one of these builds instead..

iot/lxqt have bonescript/etc working with v4.4.x.

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01

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

[beagleboard] CCCCCCC's Debug serial port output on unsuccessful boot

[Matt99eo]

Working with a BBB that has a custom hardware cape on it.

Sometimes I get an unsuccessful boot out of it where when connected to the 
serial debug part I see the letter C printed indefinitely.

I'd say 90% of the boot attempts work (serial debug looks normal) and 10% I 
get the infinite C printout and no successful boot.  


Any ideas?

-- 
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/965be62d-660c-432e-887f-9f92ff671d44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Any difference for PIN9.15 (GPIO1_16) on new BBB

[Gerald Coley]

They come up as inputs.

Gerald


On Mon, May 2, 2016 at 2:38 PM,  wrote:

> So, Gerald,
> Why do you think it is an acceptable condition to to have GPIO1_16
> fighting GPIO2_0 on boot up, and perhaps forever for the case that a BBB
> user doesn't happen to notice this condition, which violates the AM3358
> recommended operating conditions? Ref: TI SPRS717J –OCTOBER 2011–REVISED
> APRIL 2016 page 92, VOH and VOL, normal operation characteristics.
> John C.
>
> On Tuesday, June 4, 2013 at 3:29:51 PM UTC-4, Gerald wrote:
>>
>> Yes it is. I added the ability to bring out the MMC2 CMD
>> line. Unsoldering the resistor is what they are there for. No sadness
>> needed. Sadness only in the SW was unable to control the HW correctly.
>>
>> Gerald
>>
>>
>>
>> On Tue, Jun 4, 2013 at 2:18 PM, Juanjo  wrote:
>>
>>> Update,
>>>
>>> Indeed PIN9.15 on BBB is a _bit_ different than old BB. Seeing
>>> schematics one can see that T13 (GPIO2_0) is also connected on PIN9.15, on
>>> the original BB only R13 (GPIO1_16) was connected to pin 9.15.
>>>
>>> So now GPIO1_16 and also GPIO2_0 is connected to PIN9.15. Sadly T13
>>> (GPIO2_0) seems to start as GPMC or MMC2 or something that gets you
>>> 1.0-1.6V on this pin on start which could lead to problems on power up on
>>> some capes.
>>>
>>> By now I just desoldered R161 (which connects T13 to PIN9.15) but I´ll
>>> change my design to use another pin which do start at 0V on powerup.
>>>
>>>
>>> On Monday, June 3, 2013 5:35:22 PM UTC-4, Juanjo wrote:

 BTW,

 I must add that on my white BeagleBone I'm running the exact same
 kernel that on the BBB which is 3.8.13-bone20. I was on understanding that
 the DTS are applied the same on the BBW and BBB for 3.8.

 It seems that for 3.8.13 on the BBB the DTS that are loaded before any
 overlay change PIN9.15 mux or just reset it to mode 0. But I cannot find
 any mention to gpmc_a0 on those DTS/DTSI :(

 On Monday, June 3, 2013 5:25:00 PM UTC-4, Juanjo wrote:
>
> Thanks Gerald !
>
> On Monday, June 3, 2013 4:41:13 PM UTC-4, Gerald wrote:
>>
>> The 3.8 does not affect what is needed to control the pins, That is
>> all protected by hardware in the chip. The 3.8 kernel does affect how 
>> pins
>> are controlled with things like overlays. I suggest you read
>> the document located at https://docs.google.com/
>> document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub . It
>> should answer some of your questions.
>>
>> Gerald
>>
>>
>>
>> On Mon, Jun 3, 2013 at 3:32 PM, Juanjo  wrote:
>>
>>> Thanks Gerald,
>>>
>>> I managed to set the pin on early init on uBoot and it does work.
>>> But afterward when Kernel is booting it changes the pin back :( and keep
>>> that way until I set out direction on the GPIO using Linux gpio 
>>> interface.
>>>
>>> I wonder if the pin mux kernel parameters defined on
>>> http://processors.wiki.ti.com/index.php/AM335x_PSP_User's_Guide
>>> still applies to 3.8.X
>>>
>>> On Monday, June 3, 2013 3:06:28 PM UTC-4, Juanjo wrote:

 Guys,

 On my cape I use PIN9.15 (GPIO1_16) to control an ON/OFF process
 through a NPN transistor. This cape worked just right on white BB. Now 
 I´m
 trying the cape on a new BBB I noted that the power on process is 
 started
 just when the BBB is powered up and I need to start the process after 
 a few
 conditions are met.

 I noted that on my white Beaglebone once power is up and uBoot
 starts this PIN stay low just as expected (isn´t in SYSBOOT) but on 
 the BBB
 it starts at 1.0 - 1.6V which starts my process earlier than it should.

 I played in uBoot with "gpio clear 48" which do sets the pin low
 but then the Kernel starts and it switch to 1.6V again and I´m setting 
 pin
 muxing through a DTBO which describes my cape. But the level goes low 
 just
 after I use "echo out > /sys/class/gpio/gpio48/direction" on
 Linux. Even I forced the muxing of this pin to GPIO1_16 on uBoot and
 recompile but somewhere is changed back to 1.6V on uBoot and in the 
 Kernel
 afterward.

 PIN9.15 is GPIO1_16, gmpc_a0, gmii_ and rmii_ something which AFAIK
 isn't used for anything on the new BBB it isn't a SYSBOOT pin so I 
 can't
 figure why this pin is starting at 1.6V and even changing it to 0V 
 using
 uEnv.txt after Kernel boot it goes to 1.6V again.

 Any help would be appreciated.

 Thanks

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

[beagleboard] 1-24-16 Debian 8.3 Jessie -- not working

[jason . muller . 4280]

Hello, I am a novice when it comes to using the BBB. I have a revC and I 
have just started to play around with it. I have just updated the board to 
the latest image from the beagleboard.org/latest-images web site, which is 
the Debian 8.3 "Jessie" build from 24-Jan, and I cannot get anything to 
work via Bonescript on this build.

Upon unboxing I had previously played around a little with blinking the 
on-board LEDs as per the "getting started" tutorial. Using Cloud9 I was 
able to run the LED3 1s "blink" cycle, set one of the GPIO pins to output a 
PWM wave, etc. Due to repeating problems when connecting a USB hub (for 
hooking up mouse & keyboard) I decided to upgrade the OS image to the 
above. 

After performing this task, I am happy to report that the USB hub now works 
perfectly. However, nothing else does! And by this I mean that I cannot 
execute anything via Bonescript. Say, for example, I browse to the "getting 
started" tutorial at 127.0.0.1. There is a box that you can click that 
should turn on all 4 user LEDs for 2s. This box is grayed out and does not 
work.

And if I go to Cloud9 and try to execute anything, I get the following 
output in the debugger:

+

debugger listening on port 15454
info: Error writing to /sys/kernel/debug/omap_mux/gpmc_ad9: Error: EACCES, 
permission denied '/sys/kernel/debug/omap_mux/gpmc_ad9'

fs.js:443
  return binding.open(pathModule._makeLong(path), stringToFlags(flags), 
mode);
 ^
Error: ENOENT, no such file or directory 'undefined/run'
at Object.fs.openSync (fs.js:443:18)
at Object.fs.writeFileSync (fs.js:982:15)
at Object.exports.writePWMFreqAndValue 
(/usr/local/lib/node_modules/bonescript/src/hw_oldkernel.js:167:12)
at Object.f.analogWrite 
(/usr/local/lib/node_modules/bonescript/src/index.js:448:15)
at Object. (/var/lib/cloud9/PWM-P8_13.js:2:3)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain [as _onTimeout] (module.js:497:10)


Process exited with code: 8

+

It seems to me like this image is not setup to run Bonescript out of the 
box. Can anyone tell me what is going on? Should I switch to some different 
OS image, or is there a way to fix this one, or am I making some user 
error...?

I am not sure how relevant the following information is. But I will also 
mention that I verified the downloaded SD card image with the SHA-256 hash, 
and it was OK. Also I have programmed the eMMC from the SD card & am 
booting off that (as opposed to running directly from the SD card). And 
finally I have done nothing to modify the image in any way. 

Thanks in advance. 

-- 
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/e3df68a0-6598-4c97-b136-373d9298bd8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Any difference for PIN9.15 (GPIO1_16) on new BBB

[jcarrick]

So, Gerald,
Why do you think it is an acceptable condition to to have GPIO1_16 fighting 
GPIO2_0 on boot up, and perhaps forever for the case that a BBB user 
doesn't happen to notice this condition, which violates the AM3358 
recommended operating conditions? Ref: TI SPRS717J –OCTOBER 2011–REVISED 
APRIL 2016 page 92, VOH and VOL, normal operation characteristics.
John C.

On Tuesday, June 4, 2013 at 3:29:51 PM UTC-4, Gerald wrote:
>
> Yes it is. I added the ability to bring out the MMC2 CMD 
> line. Unsoldering the resistor is what they are there for. No sadness 
> needed. Sadness only in the SW was unable to control the HW correctly.
>
> Gerald
>
>
> On Tue, Jun 4, 2013 at 2:18 PM, Juanjo  
> wrote:
>
>> Update,
>>
>> Indeed PIN9.15 on BBB is a _bit_ different than old BB. Seeing schematics 
>> one can see that T13 (GPIO2_0) is also connected on PIN9.15, on the 
>> original BB only R13 (GPIO1_16) was connected to pin 9.15.
>>
>> So now GPIO1_16 and also GPIO2_0 is connected to PIN9.15. Sadly T13 
>> (GPIO2_0) seems to start as GPMC or MMC2 or something that gets you 
>> 1.0-1.6V on this pin on start which could lead to problems on power up on 
>> some capes.
>>
>> By now I just desoldered R161 (which connects T13 to PIN9.15) but I´ll 
>> change my design to use another pin which do start at 0V on powerup.
>>
>>
>> On Monday, June 3, 2013 5:35:22 PM UTC-4, Juanjo wrote:
>>>
>>> BTW,
>>>
>>> I must add that on my white BeagleBone I'm running the exact same kernel 
>>> that on the BBB which is 3.8.13-bone20. I was on understanding that the DTS 
>>> are applied the same on the BBW and BBB for 3.8.
>>>
>>> It seems that for 3.8.13 on the BBB the DTS that are loaded before any 
>>> overlay change PIN9.15 mux or just reset it to mode 0. But I cannot find 
>>> any mention to gpmc_a0 on those DTS/DTSI :(
>>>
>>> On Monday, June 3, 2013 5:25:00 PM UTC-4, Juanjo wrote:

 Thanks Gerald !

 On Monday, June 3, 2013 4:41:13 PM UTC-4, Gerald wrote:
>
> The 3.8 does not affect what is needed to control the pins, That is 
> all protected by hardware in the chip. The 3.8 kernel does affect how 
> pins 
> are controlled with things like overlays. I suggest you read 
> the document located at https://docs.google.com/
> document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub . It 
> should answer some of your questions.
>
> Gerald
>
>
>
> On Mon, Jun 3, 2013 at 3:32 PM, Juanjo  wrote:
>
>> Thanks Gerald,
>>
>> I managed to set the pin on early init on uBoot and it does work. But 
>> afterward when Kernel is booting it changes the pin back :( and keep 
>> that 
>> way until I set out direction on the GPIO using Linux gpio interface.
>>
>> I wonder if the pin mux kernel parameters defined on 
>> http://processors.wiki.ti.com/index.php/AM335x_PSP_User's_Guide 
>> still applies to 3.8.X
>>
>> On Monday, June 3, 2013 3:06:28 PM UTC-4, Juanjo wrote:
>>>
>>> Guys,
>>>
>>> On my cape I use PIN9.15 (GPIO1_16) to control an ON/OFF process 
>>> through a NPN transistor. This cape worked just right on white BB. Now 
>>> I´m 
>>> trying the cape on a new BBB I noted that the power on process is 
>>> started 
>>> just when the BBB is powered up and I need to start the process after a 
>>> few 
>>> conditions are met.
>>>
>>> I noted that on my white Beaglebone once power is up and uBoot 
>>> starts this PIN stay low just as expected (isn´t in SYSBOOT) but on the 
>>> BBB 
>>> it starts at 1.0 - 1.6V which starts my process earlier than it should. 
>>>
>>> I played in uBoot with "gpio clear 48" which do sets the pin low but 
>>> then the Kernel starts and it switch to 1.6V again and I´m setting pin 
>>> muxing through a DTBO which describes my cape. But the level goes low 
>>> just 
>>> after I use "echo out > /sys/class/gpio/gpio48/direction" on Linux. 
>>> Even I forced the muxing of this pin to GPIO1_16 on uBoot and recompile 
>>> but 
>>> somewhere is changed back to 1.6V on uBoot and in the Kernel afterward.
>>>
>>> PIN9.15 is GPIO1_16, gmpc_a0, gmii_ and rmii_ something which AFAIK 
>>> isn't used for anything on the new BBB it isn't a SYSBOOT pin so I 
>>> can't 
>>> figure why this pin is starting at 1.6V and even changing it to 0V 
>>> using 
>>> uEnv.txt after Kernel boot it goes to 1.6V again.
>>>
>>> Any help would be appreciated.
>>>
>>> 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...@googlegroups.com.
>> For more options, visit 

[beagleboard] Setting UART speed on BBB Rev C

[Pierce Nichols]

Hi all,

I posted this to the Beaglebone list as well, but it seems a bit dead
so I'm reposting here.

I would like to find a way to set the speed of the UARTs to something
other than the standard speeds offered by termios.

I'm running a BBB Rev C with Debian 8.3, stock kernel from
beaglebone.org. I'm using the universal cape and config-pin for setup
(because it works well enough, so far). I currently have it working
with a serial speed of 115.2 kbps, but the listener can't handle any
of the standard termios speeds above that. It can handle 250, 500, or
1000 kbps, however. How can I set the BBB UARTs to operate at one of
those speeds?

-p

PS -- I've considered shifting over to SPI on the next hardware rev,
but that will be a little bit and I'd like more speed now.

-- 
Pierce Nichols
Principal Engineer
Logos Electromechanical, LLC

-- 
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/CAENK0Pz5t2FyDi-b42krTfZayFEUB_vBV%2BqqiKKFtz0NKFK0TQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] debian testing: 2016-05-01

[Rick Mann]

> On May 2, 2016, at 13:14 , Jason Kridner  wrote:
> 
> 
> 
> On Mon, May 2, 2016 at 3:52 PM Rick Mann  wrote:
> 
> > On May 2, 2016, at 07:49 , Robert Nelson  wrote:
> >
> > So there's a little something new in this week's snapshot:
> >
> > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01
> >
> > We've now switched from v4.1.x-ti to v4.4.x-ti by default.
> 
> So, if I want to use PRUSS, I need to grab a -bone kernel, right?
> 
> If using remoteproc, the -ti kernel should be OK. If you need uio_pruss, then 
> I think you still need -bone. Not sure if there is progress on making this 
> device tree adjustable.

Yeah, sorry. By PRUSS I meant uio_pruss. I depend on a third-party lib that 
uses that and isn't like to be updated any time soon. I don't have time to 
learn how to update it right now, given all the other things I have to finish 
on this project.

-- 
Rick Mann
rm...@latencyzero.com


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7FDC817A-E6F2-431A-9128-6C0D3C514118%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] debian testing: 2016-05-01

[Jason Kridner]

On Mon, May 2, 2016 at 3:52 PM Rick Mann  wrote:

>
> > On May 2, 2016, at 07:49 , Robert Nelson 
> wrote:
> >
> > So there's a little something new in this week's snapshot:
> >
> > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01
> >
> > We've now switched from v4.1.x-ti to v4.4.x-ti by default.
>
> So, if I want to use PRUSS, I need to grab a -bone kernel, right?
>

If using remoteproc, the -ti kernel should be OK. If you need uio_pruss,
then I think you still need -bone. Not sure if there is progress on making
this device tree adjustable.


>
> > Wireless AP by default:
>
> Ooh!
>
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/35D3AB97-FBA4-4EC3-A165-39C2A4E612F0%40latencyzero.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/CA%2BT6QPn8uUFcsLtrjy7ts4dn1fe3D4xLwcYruFBEU27reuO4kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beagle-alpha] debian testing: 2016-05-01

[Jason Kridner]

On Mon, May 2, 2016 at 10:50 AM Robert Nelson 
wrote:

> Howdy!
>
> So there's a little something new in this week's snapshot:
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01
>
> We've now switched from v4.1.x-ti to v4.4.x-ti by default.
>

With 4.4, should we be enabling -rt?


>
> hostap/wpasuppliant saw a major upgrade: 2.3 -> 2.5
>

Does this image include the WL183x patches from TI?


>
> Board specific documentation:
>
> BBW/BBB = BeagleBoard.org documentation over usb flash
>
> BBG = seeedstudio.com documentation over usb flash
>
> bonescript 0.5.0-beta with more fixes
>

I'm assuming beta4. I'll try to get the fix in if using the old cape
manager to continue using the old functions. All should be working better
for the newer kernels.


>
> nodejs v0.12.x
>
> Wireless AP by default:
>
> SSID: BeagleBone (or) BeagleBone-WXYZ
>

When would you not have the -WXYZ?


> PASS: BeagleBone
>

Can you summarize connman vs. other configs for the various network
connections?


>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Beagle Alpha" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagle-alpha+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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPkGDbfx-_4odKMXsraQAEN25-uvNyWNYh1rRUfLhE39Ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] debian testing: 2016-05-01

[Rick Mann]

> On May 2, 2016, at 07:49 , Robert Nelson  wrote:
> 
> So there's a little something new in this week's snapshot:
> 
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01
> 
> We've now switched from v4.1.x-ti to v4.4.x-ti by default.

So, if I want to use PRUSS, I need to grab a -bone kernel, right?

> Wireless AP by default:

Ooh!


-- 
Rick Mann
rm...@latencyzero.com


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/35D3AB97-FBA4-4EC3-A165-39C2A4E612F0%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Power - shutdown

[Yiannis Papelis]

Mike,

Thanks for the suggestion, this seems like a viable alternative.

On Monday, May 2, 2016 at 3:02:57 PM UTC-4, mjc wrote:
>
> On 05/02/2016 02:54 PM, Yiannis Papelis wrote: 
> > Very much agree with you - even though I don't want to use a battery, it 
> > seems more and more than a battery is a necessity for field use of the 
> > BBB, which would explain the existing connector. 
>
> In my work, the solution was to use a read-only filesystem with a tmpfs 
> overlay. I mount the boot and root partitions read-only, and configure 
> /etc/sysconfig/readonly-root with READONLY=yes and TEMPORARY_STATE=yes. 
> (This system runs Fedora.) 
>
> Permanent file writes are not frequently needed, but the filesystems can 
> be temporarily re-mounted as read/write when they are required. 
>
> Also, I use a Swissbit SD card, which is more robust (and expensive) 
> than normal SD cards, because it contains additional power-down 
> protection. 
>
> I haven't experienced any filesystem corruption since switching to this 
> approach. 
>
> I did use supercaps as pseudo-battery-backups for a while - the program 
> would switch the filesystem to readonly as soon as a powerfail circuit 
> was tripped - but the readonly+overlay approach is simpler and more 
> robust in practice. 
>
> - Mike 
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/184788e1-295e-46d0-a5ac-a168a061eeb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Power - shutdown

[Dr. Michael J. Chudobiak]

On 05/02/2016 02:54 PM, Yiannis Papelis wrote:

Very much agree with you - even though I don't want to use a battery, it
seems more and more than a battery is a necessity for field use of the
BBB, which would explain the existing connector.


In my work, the solution was to use a read-only filesystem with a tmpfs 
overlay. I mount the boot and root partitions read-only, and configure 
/etc/sysconfig/readonly-root with READONLY=yes and TEMPORARY_STATE=yes. 
(This system runs Fedora.)


Permanent file writes are not frequently needed, but the filesystems can 
be temporarily re-mounted as read/write when they are required.


Also, I use a Swissbit SD card, which is more robust (and expensive) 
than normal SD cards, because it contains additional power-down protection.


I haven't experienced any filesystem corruption since switching to this 
approach.


I did use supercaps as pseudo-battery-backups for a while - the program 
would switch the filesystem to readonly as soon as a powerfail circuit 
was tripped - but the readonly+overlay approach is simpler and more 
robust in practice.


- Mike

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/577c2f3b-dc9c-184f-8e04-088aa602144e%40avtechpulse.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Power - shutdown

[Yiannis Papelis]

As someone already posted, this is a bit more complicated than that, but I 
get the idea.

On Monday, May 2, 2016 at 2:09:44 PM UTC-4, William Hermans wrote:
>
> *Use a super capacitor.*
>>
>
> Ok, a little abstract . . .
>
> Use a super capacitor, and if using a console image . . .  sudo apt-get 
> install acpid
>
> Then the board will automatically shutdown when 5V input goes missing. I'd 
> make sure you pick a super cap that can sustain the beaglebone for ~30 
> seconds, even if not needed. Just in case. Typically though, here, we see 
> that the board shuts down within 5 seconds or so. Maybe slightly longer. 
>
> On Mon, May 2, 2016 at 10:47 AM, William Hermans  > wrote:
>
>> *I have been building embedded systems for a while now and I am 
>>> considering using the beaglebone (BBB) for an upcoming project, but I am 
>>> confused by everything I read regarding the shutdown requirements. As an 
>>> embedded system the only way to turn it off is to simply shutdown the power 
>>> with a switch, yet my preliminary research indicates that this is a no-no 
>>> as it may damage the BBB and/or corrupt the file system.  I also read a lot 
>>> of comments regarding voltage on the pins after a shutdown; in my case, 
>>> very likely there will be a CAT5 cable with live activity connected even 
>>> after power down; assume the magnetics should protect the BBB, but just 
>>> checking.*
>>>
>>
>> This is true of any system running an OS that is not red only. If you 
>> unceremoniously yank the power, you're asking for trouble.
>>
>> *I have used quite a few micro controllers and various self-standing 
>>> systems, but am fairly new to the BBB - still mostly reading about it.  Am 
>>> I missing something?  How can a device meant to be used in embedded systems 
>>> not be tolerant of power loss and be so finicky about power?*
>>>
>>
>> It sounds like you're missing a lot. It sounds like you've had a lot of 
>> experience with small micros, that run bare metal, but have have no, or 
>> limited experience with using an embedded OS. 
>>
>> Then if you stop and think of the cost of this board, and what the goal 
>> of beagleboard.org was when the board was created. Perhaps then it 
>> become clear as to how / why we're where we are in this context. You can 
>> fix all of this yourself, using external hardware, and custom software.
>>
>>>
>>> *By the way, I can see there is a battery backup circuit but I do not 
>>> want to use a lithium battery for safety/temperature/cost reasons.  Using a 
>>> large capacitor also seems tricky as the shutdown may take a few seconds so 
>>> I don't see how that will work.*
>>>
>>> *Any suggestions would be greatly appreciated.*
>>
>>
>> Use a super capacitor.
>>
>>
>>
>> On Mon, May 2, 2016 at 8:39 AM, Gerald Coley > > wrote:
>>
>>>
>>>
>>> On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis >> > wrote:
>>>
 I have been building embedded systems for a while now and I am 
 considering using the beaglebone (BBB) for an upcoming project, but I am 
 confused by everything I read regarding the shutdown requirements. As an 
 embedded system the only way to turn it off is to simply shutdown the 
 power 
 with a switch, yet my preliminary research indicates that this is a no-no 
 as it may damage the BBB and/or corrupt the file system.  I also read a 
 lot 
 of comments regarding voltage on the pins after a shutdown; in my case, 
 very likely there will be a CAT5 cable with live activity connected even 
 after power down; assume the magnetics should protect the BBB, but just 
 checking.

 I have used quite a few micro controllers and various self-standing 
 systems, but am fairly new to the BBB - still mostly reading about it.  Am 
 I missing something?  How can a device meant to be used in embedded 
 systems 
 not be tolerant of power loss and be so finicky about power?

 By the way, I can see there is a battery backup circuit but I do not 
 want to use a lithium battery for safety/temperature/cost reasons.  Using 
 a 
 large capacitor also seems tricky as the shutdown may take a few seconds 
 so 
 I don't see how that will work.

 Any suggestions 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...@googlegroups.com .
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/beagleboard/4b2dc307-631d-405d-88d6-7537adb3ac29%40googlegroups.com
  
 
 .
 For more options, visit 

Re: [beagleboard] Power - shutdown

[Yiannis Papelis]

William,

Thank you for following up - I appreciate the responses.

On Monday, May 2, 2016 at 1:47:45 PM UTC-4, William Hermans wrote:
>
> *I have been building embedded systems for a while now and I am 
>> considering using the beaglebone (BBB) for an upcoming project, but I am 
>> confused by everything I read regarding the shutdown requirements. As an 
>> embedded system the only way to turn it off is to simply shutdown the power 
>> with a switch, yet my preliminary research indicates that this is a no-no 
>> as it may damage the BBB and/or corrupt the file system.  I also read a lot 
>> of comments regarding voltage on the pins after a shutdown; in my case, 
>> very likely there will be a CAT5 cable with live activity connected even 
>> after power down; assume the magnetics should protect the BBB, but just 
>> checking.*
>>
>
> This is true of any system running an OS that is not red only. If you 
> unceremoniously yank the power, you're asking for trouble.
>
Everyone keeps using the same sentence "you're asking for trouble" but 
without any more details on why that is the case.  I get the file system 
corruption issue, just wanting to make sure there isn't anything else.
 

>
> *I have used quite a few micro controllers and various self-standing 
>> systems, but am fairly new to the BBB - still mostly reading about it.  Am 
>> I missing something?  How can a device meant to be used in embedded systems 
>> not be tolerant of power loss and be so finicky about power?*
>>
>
> It sounds like you're missing a lot. It sounds like you've had a lot of 
> experience with small micros, that run bare metal, but have have no, or 
> limited experience with using an embedded OS. 
>
I have used quite a few 'small micros', SBCs, DSPs with anything from bare 
metal, VxWorks, Linux and all kids of things, including a hardened laptop 
pretending to be a stand-alone SBC.  But that's not the point, most devices 
targeting embedded computing aren't as fragile, or if they are, they 
include embedded circuitry to ensure orderly shutdown in case power is 
yanked, which is how you turn off a stand-alone system.  In my lab, we have 
several robots using the Edison and logging process writing to SD card with 
no external power management electronics other than a switch.  Over a 
couple of years of heavy use, there has been no issue.
   

>
> Then if you stop and think of the cost of this board, and what the goal of 
> beagleboard.org was when the board was created. Perhaps then it become 
> clear as to how / why we're where we are in this context. You can fix all 
> of this yourself, using external hardware, and custom software.
>
>>
>> *By the way, I can see there is a battery backup circuit but I do not 
>> want to use a lithium battery for safety/temperature/cost reasons.  Using a 
>> large capacitor also seems tricky as the shutdown may take a few seconds so 
>> I don't see how that will work.*
>>
> I have no problem handling this with external electronics (although it 
tilts the cost-reward curve a bit), I am just making sure that it is indeed 
necessary.

 

> *Any suggestions would be greatly appreciated.*
>
>
> Use a super capacitor.
>
>
>
> On Mon, May 2, 2016 at 8:39 AM, Gerald Coley  > wrote:
>
>>
>>
>> On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis > > wrote:
>>
>>> I have been building embedded systems for a while now and I am 
>>> considering using the beaglebone (BBB) for an upcoming project, but I am 
>>> confused by everything I read regarding the shutdown requirements. As an 
>>> embedded system the only way to turn it off is to simply shutdown the power 
>>> with a switch, yet my preliminary research indicates that this is a no-no 
>>> as it may damage the BBB and/or corrupt the file system.  I also read a lot 
>>> of comments regarding voltage on the pins after a shutdown; in my case, 
>>> very likely there will be a CAT5 cable with live activity connected even 
>>> after power down; assume the magnetics should protect the BBB, but just 
>>> checking.
>>>
>>> I have used quite a few micro controllers and various self-standing 
>>> systems, but am fairly new to the BBB - still mostly reading about it.  Am 
>>> I missing something?  How can a device meant to be used in embedded systems 
>>> not be tolerant of power loss and be so finicky about power?
>>>
>>> By the way, I can see there is a battery backup circuit but I do not 
>>> want to use a lithium battery for safety/temperature/cost reasons.  Using a 
>>> large capacitor also seems tricky as the shutdown may take a few seconds so 
>>> I don't see how that will work.
>>>
>>> Any suggestions 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 

Re: [beagleboard] Power - shutdown

[Yiannis Papelis]

Very much agree with you - even though I don't want to use a battery, it 
seems more and more than a battery is a necessity for field use of the BBB, 
which would explain the existing connector.

On Monday, May 2, 2016 at 2:29:18 PM UTC-4, john3909 wrote:
>
> You cannot just use a supercap. You have to use a boost switching 
> regulator to keep the voltage on the processor constant while the supercap 
> discharges. 
> This is a lot more complicated than you suggest. You also have to deal 
> with the case of brown outs where the power is only off for fractions of a 
> seconds or cases where the power comes on and then off again before the 
> board has fully powered up. This requires a power monitor and a state 
> machine to only power the board on once the supercap is fully charged. 
> Also, if you don’t recycle the power after a power fail, the BBB has the 
> potential to lock and remains locked until the power is recycled. 
>
> Regards,
> John
>
>
>
>
> On May 2, 2016, at 11:09 AM, William Hermans  > wrote:
>
> *Use a super capacitor.*
>>
>
> Ok, a little abstract . . .
>
> Use a super capacitor, and if using a console image . . .  sudo apt-get 
> install acpid
>
> Then the board will automatically shutdown when 5V input goes missing. I'd 
> make sure you pick a super cap that can sustain the beaglebone for ~30 
> seconds, even if not needed. Just in case. Typically though, here, we see 
> that the board shuts down within 5 seconds or so. Maybe slightly longer. 
>
> On Mon, May 2, 2016 at 10:47 AM, William Hermans  > wrote:
>
>> *I have been building embedded systems for a while now and I am 
>>> considering using the beaglebone (BBB) for an upcoming project, but I am 
>>> confused by everything I read regarding the shutdown requirements. As an 
>>> embedded system the only way to turn it off is to simply shutdown the power 
>>> with a switch, yet my preliminary research indicates that this is a no-no 
>>> as it may damage the BBB and/or corrupt the file system.  I also read a lot 
>>> of comments regarding voltage on the pins after a shutdown; in my case, 
>>> very likely there will be a CAT5 cable with live activity connected even 
>>> after power down; assume the magnetics should protect the BBB, but just 
>>> checking.*
>>>
>>
>> This is true of any system running an OS that is not red only. If you 
>> unceremoniously yank the power, you're asking for trouble.
>>
>> *I have used quite a few micro controllers and various self-standing 
>>> systems, but am fairly new to the BBB - still mostly reading about it.  Am 
>>> I missing something?  How can a device meant to be used in embedded systems 
>>> not be tolerant of power loss and be so finicky about power?*
>>>
>>
>> It sounds like you're missing a lot. It sounds like you've had a lot of 
>> experience with small micros, that run bare metal, but have have no, or 
>> limited experience with using an embedded OS. 
>>
>> Then if you stop and think of the cost of this board, and what the goal of
>>  beagleboard.org was when the board was created. Perhaps then it become 
>> clear as to how / why we're where we are in this context. You can fix all 
>> of this yourself, using external hardware, and custom software.
>>
>>>
>>> *By the way, I can see there is a battery backup circuit but I do not 
>>> want to use a lithium battery for safety/temperature/cost reasons.  Using a 
>>> large capacitor also seems tricky as the shutdown may take a few seconds so 
>>> I don't see how that will work.*
>>>
>>> *Any suggestions would be greatly appreciated.*
>>
>>
>> Use a super capacitor.
>>
>>
>>
>> On Mon, May 2, 2016 at 8:39 AM, Gerald Coley > > wrote:
>>
>>>
>>>
>>> On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis >> > wrote:
>>>
 I have been building embedded systems for a while now and I am 
 considering using the beaglebone (BBB) for an upcoming project, but I am 
 confused by everything I read regarding the shutdown requirements. As an 
 embedded system the only way to turn it off is to simply shutdown the 
 power 
 with a switch, yet my preliminary research indicates that this is a no-no 
 as it may damage the BBB and/or corrupt the file system.  I also read a 
 lot 
 of comments regarding voltage on the pins after a shutdown; in my case, 
 very likely there will be a CAT5 cable with live activity connected even 
 after power down; assume the magnetics should protect the BBB, but just 
 checking.

 I have used quite a few micro controllers and various self-standing 
 systems, but am fairly new to the BBB - still mostly reading about it.  Am 
 I missing something?  How can a device meant to be used in embedded 
 systems 
 not be tolerant of power loss and be so finicky about power?

 By the way, I can see there is a battery backup circuit but I do not 
 want to use a lithium battery for 

[beagleboard] wifi connects then drops during init (Debian 8.4)

[Andrew Kirch]

Robert Nelson pointed out that the issue blocking wifi is connmand, and not 
systemd/rfkill.  I've fixed that but have run into another issue.  Wifi 
starts, associates and grabs a DHCP address during init.  While init is 
coming up, wifi closes the association, and re-starts, but without 
association, and without DHCP. (log below).  systemctl --failed shows 
connmand-wait-online failed (log below init log).  Any idea why wifi is 
associating, and then dropping seconds later? 

 [   13.459685] cfg80211: Calling CRDA to update world regulatory domain
[   13.581463] cfg80211: World regulatory domain updated:
[   13.590618] cfg80211:  DFS Master region: unset
[   13.602688] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[   13.617231] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 
2000 mBm), (N/A)
[   13.631355] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 
2000 mBm), (N/A)
[   13.633751] rtl8192cu: Chip version 0x10
[   13.638091] random: nonblocking pool is initialized
[   13.666471] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 
2000 mBm), (N/A)
[   13.682709] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 
KHz AUTO), (N/A, 2000 mBm), (N/A)
[   13.699345] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 
KHz AUTO), (N/A, 2000 mBm), (0 s)
[   13.720719] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 
2000 mBm), (0 s)
[   13.734721] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 
2000 mBm), (N/A)
[   13.751843] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), 
(N/A, 0 mBm), (N/A)
[   13.759085] rtl8192cu: MAC address: 00:9e:95:9b:56:16
[   13.759097] rtl8192cu: Board Type 0
[   13.759269] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[   13.759456] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[   13.815513] usbcore: registered new interface driver rtl8192cu
[  OK  ] Created slice system-systemd\x2drfkill.slice.
 Starting Load/Save RF Kill Switch Status of rfkill0...
[  OK  ] Started Load/Save RF Kill Switch Status of rfkill0.
[   14.388715] rtl8192cu: MAC auto ON okay!
[   14.426721] rtl8192cu: Tx queue select: 0x05
[   15.052593] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   17.197677] wlan0: authenticate with c2:56:27:cb:ca:bb
[   17.222702] wlan0: send auth to c2:56:27:cb:ca:bb (try 1/3)
[   17.234620] wlan0: authenticated
[   17.243763] wlan0: associate with c2:56:27:cb:ca:bb (try 1/3)
[   17.264677] wlan0: RX AssocResp from c2:56:27:cb:ca:bb (capab=0x431 
status=0 aid=5)
[   17.277159] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   17.283222] wlan0: associated
[  OK  ] Started LSB: Raise network interfaces..
[  OK  ] Reached target System Initialization.
[  OK  ] Listening on Avahi mDNS/DNS-SD Stack Activation Socket.
[  OK  ] Listening on cloud9.socket.
[  OK  ] Listening on bonescript.socket.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Timers.
 Starting Restore Sound Card State...
[  OK  ] Reached target Basic System.
 Starting Cape Manager Service...
 Starting Restore /etc/resolv.conf if the system cras...s shut 
down
 Starting jekyll autorun...
[  OK  ] Started jekyll autorun.
 Starting Bonescript autorun...
[  OK  ] Started Bonescript autorun.
 Starting Generic Board Startup...
 Starting Regular background program processing daemon...
[  OK  ] Started Regular background program processing daemon.
 Starting Login Service...
 Starting LSB: Start daemon at boot time...
 Starting LSB: Load kernel modules needed to enable cpufreq 
scaling...
 Starting dnsmasq - A lightweight DHCP and caching DNS server...
 Starting Avahi mDNS/DNS-SD Stack...
 Starting D-Bus System Message Bus...
[  OK  ] Started D-Bus System Message Bus.
[  OK  ] Started Avahi mDNS/DNS-SD Stack.
 Starting Connection service...
 Starting System Logging Service...
 Starting Permit User Sessions...
[  OK  ] Started Restore Sound Card State.
[  OK  ] Started Cape Manager Service.
[  OK  ] Started Restore /etc/resolv.conf if the system crash...was shut 
down..
[  OK  ] Started LSB: Start daemon at boot time.
[  OK  ] Started Permit User Sessions.
[  OK  ] Started System Logging Service.
[  OK  ] Started LSB: Load kernel modules needed to enable cpufreq scaling.
[   25.146512] wlan0: deauthenticating from c2:56:27:cb:ca:bb by local 
choice (Reason: 3=DEAUTH_LEAVING)
[   25.585228] cfg80211: Calling CRDA to update world regulatory domain
[   25.594297] using random self ethernet address
[   25.598787] using random host ethernet address
[   25.666090] using host ethernet address: 6C:EC:EB:A4:10:2B
[   25.671442] using self ethernet address: 6C:EC:EB:A4:10:20[   25.722685] 
cfg80211: World regulatory domain updated:
[   25.722702] cfg80211:  DFS Master region: 

Re: [beagleboard] Power - shutdown

[Yiannis Papelis]

Gerald,

Thanks for following up - do you mean that if I don't have anything writing 
to the file system, I can simply yank the power?

I naturally have seen the expansion header usage you listed in your 
response, is there something specific I should be looking at?


On Monday, May 2, 2016 at 11:39:53 AM UTC-4, Gerald wrote:
>
>
>
> On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis  > wrote:
>
>> I have been building embedded systems for a while now and I am 
>> considering using the beaglebone (BBB) for an upcoming project, but I am 
>> confused by everything I read regarding the shutdown requirements. As an 
>> embedded system the only way to turn it off is to simply shutdown the power 
>> with a switch, yet my preliminary research indicates that this is a no-no 
>> as it may damage the BBB and/or corrupt the file system.  I also read a lot 
>> of comments regarding voltage on the pins after a shutdown; in my case, 
>> very likely there will be a CAT5 cable with live activity connected even 
>> after power down; assume the magnetics should protect the BBB, but just 
>> checking.
>>
>> I have used quite a few micro controllers and various self-standing 
>> systems, but am fairly new to the BBB - still mostly reading about it.  Am 
>> I missing something?  How can a device meant to be used in embedded systems 
>> not be tolerant of power loss and be so finicky about power?
>>
>> By the way, I can see there is a battery backup circuit but I do not want 
>> to use a lithium battery for safety/temperature/cost reasons.  Using a 
>> large capacitor also seems tricky as the shutdown may take a few seconds so 
>> I don't see how that will work.
>>
>> Any suggestions 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/4b2dc307-631d-405d-88d6-7537adb3ac29%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> Main reason for the shutdown process is the corruption of the Linux file 
> system. 
>
> If you have power on any signal when the processor is shutdown, then you 
> are asking for trouble.
>
>
> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Pin_Usage
>
>
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/
> gco...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6412f4c6-1897-4b97-872f-bddc255dc890%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: 1-Wire

[Przemek Klosowski]

On Mon, May 2, 2016 at 11:20 AM,  wrote:
>
>
> Here the result:
> root@c0a80090:/sys/devices/w1_bus_master1# ls -lZ
>  w1_master_max_slave_count
> -r--r--r-- 1 root root ? 4096 May  2 14:45 w1_master_max_slave_count
>
> I try to use "chmod 777 w1_master_max_slave_count" and then the command
> again, but then I get:
> root@c0a80090:/sys/devices/w1_bus_master1# ls -lZ
>  w1_master_max_slave_count
> -rwxrwxrwx 1 root root ? 4096 May  2 15:18 w1_master_max_slave_count
> root@c0a80090:/sys/devices/w1_bus_master1# echo 20 >
> w1_master_max_slave_count
> bash: echo: write error: Input/output error
>
> OK, I am out of ideas---you have correctly modified the Unix filesystem
permissions, but it still doesn't work.
I see that SELinux data is missing (the '?' part). I don't remember and
can't check right now which SElinux mode is Debian in
(off/permissive/enforcing).
Check the result of 'getenforce' command.

-- 
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/CAC%3D1GgGHp40iGUx70-OA%2BqFKbXwrO_JEmOFa%3DEOdiE%3D%3D7nN-2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Power - shutdown

[John Syne]

You cannot just use a supercap. You have to use a boost switching regulator to 
keep the voltage on the processor constant while the supercap discharges. 
This is a lot more complicated than you suggest. You also have to deal with the 
case of brown outs where the power is only off for fractions of a seconds or 
cases where the power comes on and then off again before the board has fully 
powered up. This requires a power monitor and a state machine to only power the 
board on once the supercap is fully charged. Also, if you don’t recycle the 
power after a power fail, the BBB has the potential to lock and remains locked 
until the power is recycled. 

Regards,
John




> On May 2, 2016, at 11:09 AM, William Hermans  wrote:
> 
> Use a super capacitor.
> 
> Ok, a little abstract . . .
> 
> Use a super capacitor, and if using a console image . . .  sudo apt-get 
> install acpid
> 
> Then the board will automatically shutdown when 5V input goes missing. I'd 
> make sure you pick a super cap that can sustain the beaglebone for ~30 
> seconds, even if not needed. Just in case. Typically though, here, we see 
> that the board shuts down within 5 seconds or so. Maybe slightly longer. 
> 
> On Mon, May 2, 2016 at 10:47 AM, William Hermans  > wrote:
> I have been building embedded systems for a while now and I am considering 
> using the beaglebone (BBB) for an upcoming project, but I am confused by 
> everything I read regarding the shutdown requirements. As an embedded system 
> the only way to turn it off is to simply shutdown the power with a switch, 
> yet my preliminary research indicates that this is a no-no as it may damage 
> the BBB and/or corrupt the file system.  I also read a lot of comments 
> regarding voltage on the pins after a shutdown; in my case, very likely there 
> will be a CAT5 cable with live activity connected even after power down; 
> assume the magnetics should protect the BBB, but just checking.
> 
> This is true of any system running an OS that is not red only. If you 
> unceremoniously yank the power, you're asking for trouble.
> 
> I have used quite a few micro controllers and various self-standing systems, 
> but am fairly new to the BBB - still mostly reading about it.  Am I missing 
> something?  How can a device meant to be used in embedded systems not be 
> tolerant of power loss and be so finicky about power?
> 
> It sounds like you're missing a lot. It sounds like you've had a lot of 
> experience with small micros, that run bare metal, but have have no, or 
> limited experience with using an embedded OS. 
> 
> Then if you stop and think of the cost of this board, and what the goal of 
> beagleboard.org  was when the board was created. 
> Perhaps then it become clear as to how / why we're where we are in this 
> context. You can fix all of this yourself, using external hardware, and 
> custom software.
> 
> By the way, I can see there is a battery backup circuit but I do not want to 
> use a lithium battery for safety/temperature/cost reasons.  Using a large 
> capacitor also seems tricky as the shutdown may take a few seconds so I don't 
> see how that will work.
> 
> Any suggestions would be greatly appreciated.
> 
> Use a super capacitor.
> 
> 
> 
> On Mon, May 2, 2016 at 8:39 AM, Gerald Coley  > wrote:
> 
> 
> On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis  > wrote:
> I have been building embedded systems for a while now and I am considering 
> using the beaglebone (BBB) for an upcoming project, but I am confused by 
> everything I read regarding the shutdown requirements. As an embedded system 
> the only way to turn it off is to simply shutdown the power with a switch, 
> yet my preliminary research indicates that this is a no-no as it may damage 
> the BBB and/or corrupt the file system.  I also read a lot of comments 
> regarding voltage on the pins after a shutdown; in my case, very likely there 
> will be a CAT5 cable with live activity connected even after power down; 
> assume the magnetics should protect the BBB, but just checking.
> 
> I have used quite a few micro controllers and various self-standing systems, 
> but am fairly new to the BBB - still mostly reading about it.  Am I missing 
> something?  How can a device meant to be used in embedded systems not be 
> tolerant of power loss and be so finicky about power?
> 
> By the way, I can see there is a battery backup circuit but I do not want to 
> use a lithium battery for safety/temperature/cost reasons.  Using a large 
> capacitor also seems tricky as the shutdown may take a few seconds so I don't 
> see how that will work.
> 
> Any suggestions would be greatly appreciated.
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message 

Re: [beagleboard] Power - shutdown

[William Hermans]

>
> *Use a super capacitor.*
>

Ok, a little abstract . . .

Use a super capacitor, and if using a console image . . .  sudo apt-get
install acpid

Then the board will automatically shutdown when 5V input goes missing. I'd
make sure you pick a super cap that can sustain the beaglebone for ~30
seconds, even if not needed. Just in case. Typically though, here, we see
that the board shuts down within 5 seconds or so. Maybe slightly longer.

On Mon, May 2, 2016 at 10:47 AM, William Hermans  wrote:

> *I have been building embedded systems for a while now and I am
>> considering using the beaglebone (BBB) for an upcoming project, but I am
>> confused by everything I read regarding the shutdown requirements. As an
>> embedded system the only way to turn it off is to simply shutdown the power
>> with a switch, yet my preliminary research indicates that this is a no-no
>> as it may damage the BBB and/or corrupt the file system.  I also read a lot
>> of comments regarding voltage on the pins after a shutdown; in my case,
>> very likely there will be a CAT5 cable with live activity connected even
>> after power down; assume the magnetics should protect the BBB, but just
>> checking.*
>>
>
> This is true of any system running an OS that is not red only. If you
> unceremoniously yank the power, you're asking for trouble.
>
> *I have used quite a few micro controllers and various self-standing
>> systems, but am fairly new to the BBB - still mostly reading about it.  Am
>> I missing something?  How can a device meant to be used in embedded systems
>> not be tolerant of power loss and be so finicky about power?*
>>
>
> It sounds like you're missing a lot. It sounds like you've had a lot of
> experience with small micros, that run bare metal, but have have no, or
> limited experience with using an embedded OS.
>
> Then if you stop and think of the cost of this board, and what the goal of
> beagleboard.org was when the board was created. Perhaps then it become
> clear as to how / why we're where we are in this context. You can fix all
> of this yourself, using external hardware, and custom software.
>
>>
>> *By the way, I can see there is a battery backup circuit but I do not
>> want to use a lithium battery for safety/temperature/cost reasons.  Using a
>> large capacitor also seems tricky as the shutdown may take a few seconds so
>> I don't see how that will work.*
>>
>> *Any suggestions would be greatly appreciated.*
>
>
> Use a super capacitor.
>
>
>
> On Mon, May 2, 2016 at 8:39 AM, Gerald Coley 
> wrote:
>
>>
>>
>> On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis 
>> wrote:
>>
>>> I have been building embedded systems for a while now and I am
>>> considering using the beaglebone (BBB) for an upcoming project, but I am
>>> confused by everything I read regarding the shutdown requirements. As an
>>> embedded system the only way to turn it off is to simply shutdown the power
>>> with a switch, yet my preliminary research indicates that this is a no-no
>>> as it may damage the BBB and/or corrupt the file system.  I also read a lot
>>> of comments regarding voltage on the pins after a shutdown; in my case,
>>> very likely there will be a CAT5 cable with live activity connected even
>>> after power down; assume the magnetics should protect the BBB, but just
>>> checking.
>>>
>>> I have used quite a few micro controllers and various self-standing
>>> systems, but am fairly new to the BBB - still mostly reading about it.  Am
>>> I missing something?  How can a device meant to be used in embedded systems
>>> not be tolerant of power loss and be so finicky about power?
>>>
>>> By the way, I can see there is a battery backup circuit but I do not
>>> want to use a lithium battery for safety/temperature/cost reasons.  Using a
>>> large capacitor also seems tricky as the shutdown may take a few seconds so
>>> I don't see how that will work.
>>>
>>> Any suggestions 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/4b2dc307-631d-405d-88d6-7537adb3ac29%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> Main reason for the shutdown process is the corruption of the Linux file
>> system.
>>
>> If you have power on any signal when the processor is shutdown, then you
>> are asking for trouble.
>>
>>
>> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Pin_Usage
>>
>>
>> Gerald
>>
>> 

Re: [beagleboard] Power - shutdown

[William Hermans]

>
> *I have been building embedded systems for a while now and I am
> considering using the beaglebone (BBB) for an upcoming project, but I am
> confused by everything I read regarding the shutdown requirements. As an
> embedded system the only way to turn it off is to simply shutdown the power
> with a switch, yet my preliminary research indicates that this is a no-no
> as it may damage the BBB and/or corrupt the file system.  I also read a lot
> of comments regarding voltage on the pins after a shutdown; in my case,
> very likely there will be a CAT5 cable with live activity connected even
> after power down; assume the magnetics should protect the BBB, but just
> checking.*
>

This is true of any system running an OS that is not red only. If you
unceremoniously yank the power, you're asking for trouble.

*I have used quite a few micro controllers and various self-standing
> systems, but am fairly new to the BBB - still mostly reading about it.  Am
> I missing something?  How can a device meant to be used in embedded systems
> not be tolerant of power loss and be so finicky about power?*
>

It sounds like you're missing a lot. It sounds like you've had a lot of
experience with small micros, that run bare metal, but have have no, or
limited experience with using an embedded OS.

Then if you stop and think of the cost of this board, and what the goal of
beagleboard.org was when the board was created. Perhaps then it become
clear as to how / why we're where we are in this context. You can fix all
of this yourself, using external hardware, and custom software.

>
> *By the way, I can see there is a battery backup circuit but I do not want
> to use a lithium battery for safety/temperature/cost reasons.  Using a
> large capacitor also seems tricky as the shutdown may take a few seconds so
> I don't see how that will work.*
>
> *Any suggestions would be greatly appreciated.*


Use a super capacitor.



On Mon, May 2, 2016 at 8:39 AM, Gerald Coley  wrote:

>
>
> On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis 
> wrote:
>
>> I have been building embedded systems for a while now and I am
>> considering using the beaglebone (BBB) for an upcoming project, but I am
>> confused by everything I read regarding the shutdown requirements. As an
>> embedded system the only way to turn it off is to simply shutdown the power
>> with a switch, yet my preliminary research indicates that this is a no-no
>> as it may damage the BBB and/or corrupt the file system.  I also read a lot
>> of comments regarding voltage on the pins after a shutdown; in my case,
>> very likely there will be a CAT5 cable with live activity connected even
>> after power down; assume the magnetics should protect the BBB, but just
>> checking.
>>
>> I have used quite a few micro controllers and various self-standing
>> systems, but am fairly new to the BBB - still mostly reading about it.  Am
>> I missing something?  How can a device meant to be used in embedded systems
>> not be tolerant of power loss and be so finicky about power?
>>
>> By the way, I can see there is a battery backup circuit but I do not want
>> to use a lithium battery for safety/temperature/cost reasons.  Using a
>> large capacitor also seems tricky as the shutdown may take a few seconds so
>> I don't see how that will work.
>>
>> Any suggestions 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/4b2dc307-631d-405d-88d6-7537adb3ac29%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> Main reason for the shutdown process is the corruption of the Linux file
> system.
>
> If you have power on any signal when the processor is shutdown, then you
> are asking for trouble.
>
>
> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Pin_Usage
>
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BergZ8%2BPd5zBdxsHqJDzQphgPXKXF0oayzjV1PVHPY8kw%40mail.gmail.com
> 

Re: [beagleboard] apt-get install bb-node-red-installer fail

[Robert Nelson]

On Sat, Apr 30, 2016 at 12:03 PM, Wally Bkg  wrote:

> Playing around with tail -f, it turned out the unwanted node-red behavior
> was because I forgot to call fflush().
>
> This didn't matter for the usage it was originally written for.  After a
> quick recompile of the client after adding fflush() I can make very good
> use of this as a rapid prototype as it is by using the BBG as a middleman,
> but its probably better I modify the original BBW IOT application to use
> libmosquito to send message to the broker as my monitoring client exposes
> all the state variables, many of which are of no use to a client and were
> only included for test/debug purposes in the client.
>
> But my first "real use" of node-red has to be scored a success and it
> delivered a lot of functionality for minimal effort.
>
> Down the road I'll decide if its easier to mod the IOT app to use
> libmosquito or swap in a new SD card (physical access issues with the BBW).
>
> Thanks again for all the help!
>

Still works here:

root@beaglebone:~# apt-get install npm bb-node-red-installer
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
  libmagic1
Use 'apt-get autoremove' to remove it.
0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 0 not
upgraded.
Need to get 358 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://repos.rcn-ee.com/debian/ jessie/main bb-node-red-installer all
0.13.4-0rcnee1~bpo80+20160321+1 [4140 B]
Get:2 http://ftp.us.debian.org/debian/ jessie/main npm all 1.4.21+ds-2 [354
kB]
Fetched 358 kB in 0s (737 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
(Reading database ... 22326 files and directories currently installed.)
Preparing to unpack
.../bb-node-red-installer_0.13.4-0rcnee1~bpo80+20160321+1_all.deb ...
Unpacking bb-node-red-installer (0.13.4-0rcnee1~bpo80+20160321+1) over
(0.13.4-0rcnee1~bpo80+20160321+1) ...
Preparing to unpack .../npm_1.4.21+ds-2_all.deb ...
Unpacking npm (1.4.21+ds-2) over (1.4.21+ds-2) ...
Setting up bb-node-red-installer (0.13.4-0rcnee1~bpo80+20160321+1) ...
bb-node-red-installer:npm: [1.4.21]
bb-node-red-installer:node: [v0.10.42]
bb-node-red-installer:Installing: systemd-0.2.6 (for node-red)
systemd@0.2.6 /usr/local/lib/node_modules/systemd
bb-node-red-installer:Installing: node-red-0.13.4 (for node-red)

> bcrypt@0.8.5 install
/usr/local/lib/node_modules/node-red/node_modules/bcrypt
> node-gyp rebuild

make: Entering directory
'/usr/local/lib/node_modules/node-red/node_modules/bcrypt/build'
  CXX(target) Release/obj.target/bcrypt_lib/src/blowfish.o
  CXX(target) Release/obj.target/bcrypt_lib/src/bcrypt.o
  CXX(target) Release/obj.target/bcrypt_lib/src/bcrypt_node.o
  SOLINK_MODULE(target) Release/obj.target/bcrypt_lib.node
  COPY Release/bcrypt_lib.node
make: Leaving directory
'/usr/local/lib/node_modules/node-red/node_modules/bcrypt/build'
-
> utf-8-validate@1.2.1 install
/usr/local/lib/node_modules/node-red/node_modules/ws/node_modules/utf-8-validate
> node-gyp rebuild

make: Entering directory
'/usr/local/lib/node_modules/node-red/node_modules/ws/node_modules/utf-8-validate/build'
  CXX(target) Release/obj.target/validation/src/validation.o
  SOLINK_MODULE(target) Release/obj.target/validation.node
  COPY Release/validation.node
make: Leaving directory
'/usr/local/lib/node_modules/node-red/node_modules/ws/node_modules/utf-8-validate/build'
\
> bufferutil@1.2.1 install
/usr/local/lib/node_modules/node-red/node_modules/ws/node_modules/bufferutil
> node-gyp rebuild

make: Entering directory
'/usr/local/lib/node_modules/node-red/node_modules/ws/node_modules/bufferutil/build'
  CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
  SOLINK_MODULE(target) Release/obj.target/bufferutil.node
  COPY Release/bufferutil.node
make: Leaving directory
'/usr/local/lib/node_modules/node-red/node_modules/ws/node_modules/bufferutil/build'
npm WARN engine is-buffer@1.1.3: wanted: {"node":">=0.12"} (current:
{"node":"0.10.42","npm":"1.4.21"})
npm WARN engine is-buffer@1.1.3: wanted: {"node":">=0.12"} (current:
{"node":"0.10.42","npm":"1.4.21"})
npm WARN deprecated i18next-client@1.10.3: you can use npm install i18next
from version 2.0.0
\
> serialport@2.0.7-beta5 install
/usr/local/lib/node_modules/node-red/node_modules/node-red-node-serialport/node_modules/serialport
> node-pre-gyp install --fallback-to-build

make: Entering directory

[beagleboard] BeagleBone Black: IPMI Cape

[Matwey V. Kornilov]

Hello,

I've just realized that I would like to have something like IPMI cape for 
BeagleBone Black. At least, to export BBB TTL console to Ethernet.
WizNet serial-to-ethernet chip could be used in conjunction with Davicom 
DM8203 three-port fast ethernet switch chip.
Then I could have single one Ethernet uplink line for both BBB and Cape and 
the cape and BBB could be connected with patch-cord (ugly, but still).

Does anybody know whether there is already what I describe?
Unfortunately, I am not a hardware expert and If you know particular 
components which are cheaper/better than mentioned ones then please tell.

However, there are still things that I don't know how to implement yet: 
resetting BBB, switching boot order, emulating eMMC (not sure, that it is 
really needed), configuring VLANs on Ethernet switch (it would be great if 
BBB uplink and control uplink were in different VLANs), could the cape be 
powered by PoE and supply power to BBB, etc...

-- 
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/17b70ae5-bb88-4f4c-bed9-61c71e0537d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Power - shutdown

[Gerald Coley]

On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis  wrote:

> I have been building embedded systems for a while now and I am considering
> using the beaglebone (BBB) for an upcoming project, but I am confused by
> everything I read regarding the shutdown requirements. As an embedded
> system the only way to turn it off is to simply shutdown the power with a
> switch, yet my preliminary research indicates that this is a no-no as it
> may damage the BBB and/or corrupt the file system.  I also read a lot of
> comments regarding voltage on the pins after a shutdown; in my case, very
> likely there will be a CAT5 cable with live activity connected even after
> power down; assume the magnetics should protect the BBB, but just checking.
>
> I have used quite a few micro controllers and various self-standing
> systems, but am fairly new to the BBB - still mostly reading about it.  Am
> I missing something?  How can a device meant to be used in embedded systems
> not be tolerant of power loss and be so finicky about power?
>
> By the way, I can see there is a battery backup circuit but I do not want
> to use a lithium battery for safety/temperature/cost reasons.  Using a
> large capacitor also seems tricky as the shutdown may take a few seconds so
> I don't see how that will work.
>
> Any suggestions 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/4b2dc307-631d-405d-88d6-7537adb3ac29%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


Main reason for the shutdown process is the corruption of the Linux file
system.

If you have power on any signal when the processor is shutdown, then you
are asking for trouble.

http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Pin_Usage


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

[beagleboard] Power - shutdown

[Yiannis Papelis]

I have been building embedded systems for a while now and I am considering 
using the beaglebone (BBB) for an upcoming project, but I am confused by 
everything I read regarding the shutdown requirements. As an embedded 
system the only way to turn it off is to simply shutdown the power with a 
switch, yet my preliminary research indicates that this is a no-no as it 
may damage the BBB and/or corrupt the file system.  I also read a lot of 
comments regarding voltage on the pins after a shutdown; in my case, very 
likely there will be a CAT5 cable with live activity connected even after 
power down; assume the magnetics should protect the BBB, but just checking.

I have used quite a few micro controllers and various self-standing 
systems, but am fairly new to the BBB - still mostly reading about it.  Am 
I missing something?  How can a device meant to be used in embedded systems 
not be tolerant of power loss and be so finicky about power?

By the way, I can see there is a battery backup circuit but I do not want 
to use a lithium battery for safety/temperature/cost reasons.  Using a 
large capacitor also seems tricky as the shutdown may take a few seconds so 
I don't see how that will work.

Any suggestions 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/4b2dc307-631d-405d-88d6-7537adb3ac29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Second 1-wire

[hoerting . business]

Hello,

I use 1-wire on Pin P8.11

Now I want to use a second 1-wire on Pin P8.12

I made the first 1-wire with this instructions:
http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/

I wrote a new file called w2.dts
changed the exclusive pin to "P8.12" and Pin offset to "0x30" and the names 
to "w2"

I can compile and load the overlay ... but nothing is found on this Pin.

The existing 1-wire Pin is working, but the new Pin seems are not working.

Should I have a new folder called w2?

/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "BB-W2";
version = "00A0";

exclusive-use = "P8.12";

fragment@0 {
target = <_pinmux>;
__overlay__ {
 bb_w2_pins: pinmux_bb_w2_pins {
 pinctrl-single,pins =  <0x30 0x37 /* gpmc_ad13.gpio1_12, 
OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w2-$
 };
};
};

fragment@1 {
target = <>;
__overlay__ {
onewire@0 {
status  = "okay";
compatible  = "w1-gpio";
pinctrl-names   = "default";
pinctrl-0   = <_w2_pins>;

gpios = < 12 0>;
};
};
};
};


How can I setup a second 1-Wire bus?

Thank you!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bed92658-1b8c-4017-9355-8d0a8503e816%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: 1-Wire

[hoerting . business]

Hello!

Here the result:
root@c0a80090:/sys/devices/w1_bus_master1# ls -lZ  w1_master_max_slave_count
-r--r--r-- 1 root root ? 4096 May  2 14:45 w1_master_max_slave_count

I try to use "chmod 777 w1_master_max_slave_count" and then the command 
again, but then I get:
root@c0a80090:/sys/devices/w1_bus_master1# ls -lZ  w1_master_max_slave_count
-rwxrwxrwx 1 root root ? 4096 May  2 15:18 w1_master_max_slave_count
root@c0a80090:/sys/devices/w1_bus_master1# echo 20 > 
w1_master_max_slave_count
bash: echo: write error: Input/output error


-- 
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/a7f96519-33d4-49b7-8b9e-bb2d5c289bba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] debian testing: 2016-05-01

[Robert Nelson]

Howdy!

So there's a little something new in this week's snapshot:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01

We've now switched from v4.1.x-ti to v4.4.x-ti by default.

hostap/wpasuppliant saw a major upgrade: 2.3 -> 2.5

Board specific documentation:

BBW/BBB = BeagleBoard.org documentation over usb flash

BBG = seeedstudio.com documentation over usb flash

bonescript 0.5.0-beta with more fixes

nodejs v0.12.x

Wireless AP by default:

SSID: BeagleBone (or) BeagleBone-WXYZ
PASS: BeagleBone

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

Re: [beagleboard] error at boot in the image : bone-debian-8.4-lxqt-4gb-armhf-2016-04-25-4gb

[Robert Nelson]

On Mon, May 2, 2016 at 7:58 AM, Micka  wrote:

> this one :
>
> fsck: error 2 (No such file or directory) while executing fsck.ext4 for
> /dev/mmcblk0p1
>
> I don't understand it.
>

ignore it, initramfs-tools bug...


>
> also, how do you set the IP address on jessie ?
>
> /etc/network/interfaces ?
> auto eth0
> iface eth0 inet static
> address 100.91.120.21
> netmask 255.255.255.0
> gateway 100.91.120.254
>

connman is under control of eth0..

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYg9vMxw%3DSWYB-a-ozYSH5juNg4J2WYP%3DAoFOtEob76W7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] error at boot in the image : bone-debian-8.4-lxqt-4gb-armhf-2016-04-25-4gb

[Micka]

this one :

fsck: error 2 (No such file or directory) while executing fsck.ext4 for
/dev/mmcblk0p1

I don't understand it.

also, how do you set the IP address on jessie ?

/etc/network/interfaces ?
auto eth0
iface eth0 inet static
address 100.91.120.21
netmask 255.255.255.0
gateway 100.91.120.254





Le lun. 2 mai 2016 à 14:56, Robert Nelson  a
écrit :

> Hi Micka,
>
> On Mon, May 2, 2016 at 5:28 AM, Micka  wrote:
>
>> Starting kernel ...
>>
>> [3.540286] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc
>> handle
>> [3.788349] cpu cpu0: cpu0 clock notifier not ready, retry
>> [3.939012] bone_capemgr bone_capemgr: slot #0: No cape found
>> [3.999007] bone_capemgr bone_capemgr: slot #1: No cape found
>> [4.059010] bone_capemgr bone_capemgr: slot #2: No cape found
>> [4.119005] bone_capemgr bone_capemgr: slot #3: No cape found
>> Loading, please wait...
>> fsck: error 2 (No such file or directory) while executing fsck.ext4 for
>> /dev/mmcblk0p1
>> fsck exited with status code 8
>> [   11.750782] systemd[1]: Failed to set memory.limit_in_bytes on :
>> Invalid argument
>> [   12.536934] systemd-fsck[164]: rootfs: clean, 133831/217728 files,
>> 795110/870144 blocks
>> [   21.686784]  remoteproc1: failed to load am335x-pru0-fw
>> [   21.766819]  remoteproc1: request_firmware failed: -2
>> [   21.772016] pru-rproc 4a334000.pru0: rproc_boot failed
>> [   21.970925]  remoteproc1: failed to load am335x-pru1-fw
>> [   21.984090]  remoteproc1: request_firmware failed: -2
>> [   21.989339] pru-rproc 4a338000.pru1: rproc_boot failed
>>
>
>
> Correct, there are a few of them, which one is catching your eye that
> needs some explaining..
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYha_fFaJrVSy5PviyAEEVEr8uen7zi7LEfTxBYhGy3c1A%40mail.gmail.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/CAF%2BMRtntN8pcrUduhmUmbSa9Ksu9twXt%2BW3Eh9pXJ0u5NDUZjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] error at boot in the image : bone-debian-8.4-lxqt-4gb-armhf-2016-04-25-4gb

[Robert Nelson]

Hi Micka,

On Mon, May 2, 2016 at 5:28 AM, Micka  wrote:

> Starting kernel ...
>
> [3.540286] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
> [3.788349] cpu cpu0: cpu0 clock notifier not ready, retry
> [3.939012] bone_capemgr bone_capemgr: slot #0: No cape found
> [3.999007] bone_capemgr bone_capemgr: slot #1: No cape found
> [4.059010] bone_capemgr bone_capemgr: slot #2: No cape found
> [4.119005] bone_capemgr bone_capemgr: slot #3: No cape found
> Loading, please wait...
> fsck: error 2 (No such file or directory) while executing fsck.ext4 for
> /dev/mmcblk0p1
> fsck exited with status code 8
> [   11.750782] systemd[1]: Failed to set memory.limit_in_bytes on :
> Invalid argument
> [   12.536934] systemd-fsck[164]: rootfs: clean, 133831/217728 files,
> 795110/870144 blocks
> [   21.686784]  remoteproc1: failed to load am335x-pru0-fw
> [   21.766819]  remoteproc1: request_firmware failed: -2
> [   21.772016] pru-rproc 4a334000.pru0: rproc_boot failed
> [   21.970925]  remoteproc1: failed to load am335x-pru1-fw
> [   21.984090]  remoteproc1: request_firmware failed: -2
> [   21.989339] pru-rproc 4a338000.pru1: rproc_boot failed
>


Correct, there are a few of them, which one is catching your eye that needs
some explaining..

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

Re: [beagleboard] Re: Basic lock down

[Lee Armstrong]

Yes very true but the 2 easy vectors I can see are serial debug cable and
micro SD. If anything could be done to discourage it then that would be
welcomed.

Will look into encrypting the OS though. Good idea.
On Mon, 2 May 2016 at 12:49,  wrote:

> Lee Armstrong  wrote:
> > [-- text/plain, encoding 7bit, charset: UTF-8, 12 lines --]
> >
> > I have my BBB flashed onto the eMMC and it is feasible for someone to
> boot
> > from the SD Card and/or use the serial debug cable to gain access.
> >
> > What methods if any have people used to prevent some access?
> >
> What sort of 'access' are you trying to prevent?
>
> If someone has physical access then all bets are off, they just take
> the whole thing and can see all the data on it.  You can't really
> prevent that unless you install an encrypted OS.
>
> --
> Chris Green
> ·
>
> --
> 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/tDABFWGMWVE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/m1rjvc-o51.ln1%40esprimo.zbmc.eu
> .
> 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/CAC5LoL-1vPXM3OvCqTrjajieOubZrN4Dsx5rngCONoNUcogNSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Basic lock down

[cl]

Lee Armstrong  wrote:
> [-- text/plain, encoding 7bit, charset: UTF-8, 12 lines --]
> 
> I have my BBB flashed onto the eMMC and it is feasible for someone to boot 
> from the SD Card and/or use the serial debug cable to gain access. 
> 
> What methods if any have people used to prevent some access?
> 
What sort of 'access' are you trying to prevent?

If someone has physical access then all bets are off, they just take
the whole thing and can see all the data on it.  You can't really
prevent that unless you install an encrypted OS.

-- 
Chris Green
·

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/m1rjvc-o51.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] error at boot in the image : bone-debian-8.4-lxqt-4gb-armhf-2016-04-25-4gb

[Micka]

Starting kernel ...

[3.540286] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[3.788349] cpu cpu0: cpu0 clock notifier not ready, retry
[3.939012] bone_capemgr bone_capemgr: slot #0: No cape found
[3.999007] bone_capemgr bone_capemgr: slot #1: No cape found
[4.059010] bone_capemgr bone_capemgr: slot #2: No cape found
[4.119005] bone_capemgr bone_capemgr: slot #3: No cape found
Loading, please wait...
fsck: error 2 (No such file or directory) while executing fsck.ext4 for
/dev/mmcblk0p1
fsck exited with status code 8
[   11.750782] systemd[1]: Failed to set memory.limit_in_bytes on : Invalid
argument
[   12.536934] systemd-fsck[164]: rootfs: clean, 133831/217728 files,
795110/870144 blocks
[   21.686784]  remoteproc1: failed to load am335x-pru0-fw
[   21.766819]  remoteproc1: request_firmware failed: -2
[   21.772016] pru-rproc 4a334000.pru0: rproc_boot failed
[   21.970925]  remoteproc1: failed to load am335x-pru1-fw
[   21.984090]  remoteproc1: request_firmware failed: -2
[   21.989339] pru-rproc 4a338000.pru1: rproc_boot failed

-- 
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/CAF%2BMRtnp_QBFPY%3DoeVkDhH%3DJgWVY8pDfk_yJYPgX-R_At8vR7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] unnoticed issue with weather cape

[attilio . giordana]

Hallo, I've found a problem with the "weather cape" that I'm planning to 
use in a student lab.
I've bought 5 weather capes release B from Farnell. Two of them work 
perfectly with beaglebone black and Linux debian.
The other three do not allow linux to complete the bootstrap so that it 
remain impossible to interact with the board, either from the network and 
from the console. Apparently the cape are all release B. However i've 
notices that the three that do not work have a serial number initiating 
with 1514WTHR..., whereas the other two have serial number 1814WTHR 
Moreover the color of the board is slightly different.
The two working ones have a color more dark, almost like peanuts butter. My 
conclusion is that something changed in the hardware, on the way but, at 
least in my knowledge,  has not been noticed.
Does any one have idea of it could be the reason for this misbehaviour? 
I've tried all beaglebones  and  all Linux images, I'm currently using, 
with the same result. 
Thank you in advance for your attention.
Attilio Giordana

-- 
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/5b8e5337-7937-4e88-9993-7f71edd16bc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] kernel updates: 4.1.12-ti-r27 (BBB all spi/spidev users rejoice)

['Andreas Müller' via BeagleBoard]

On Thu, Nov 5, 2015 at 3:47 PM, Robert Nelson  wrote:
> The journey into spi & dma..
>
> So for awhile now, we've had a bug for spi users, where the system
> would hardlock at the "160" byte threashold:
>
> debian@beaglebone:~$ sudo dd if=/dev/zero of=/dev/spidev1.0 bs=159 count=1
> 1+0 records in
> 1+0 records out
> 159 bytes (159 B) copied, 0.000508833 s, 312 kB/s
> debian@beaglebone:/sys$ dd if=/dev/zero of=/dev/spidev1.0 bs=160 count=1
> ^C
>
> (hangs..)
>
> "160" happens to be a the magic number where DMA takes over from PIO mode...
>
> Well as of yesterday:
>
> debian@beaglebone:~$ sudo dd if=/dev/zero of=/dev/spidev1.0 bs=320 count=1
> 1+0 records in
> 1+0 records out
> 320 bytes (320 B) copied, 0.00266366 s, 120 kB/s
>
> So here's the deal, it looks to be a spi/overlay bug, as we don't seem
> to get the correct dma tx/rx channels..
>
> What interesting, when the "spi" node is enabled in the main dtb:
>
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-spi0.dts#L120-L137
>
> it works fine in dma mode...
>
> So with "4.1.12-ti-r27" spi-dma is now disabled..
>
> *btw:
>
> Late last night i wrote a better fix (will be r28)
>
> where you can disable "spi-dma" via the dt option:
>
> ti,pio-mode;
>
> https://github.com/beagleboard/bb.org-overlays/commit/48d33d4d22f284103db83626b343724cf18c578d
>
> Regards,
>
It is very long time ago, but now I am running into performance issues
with SPI. I see the DMA is still disabled in current bb.org-overlays.
So is the bug for blocks > 160 still there (what about kernel 4.4.x?)

Thanks in advance

Andreas

-- 
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/CALbNGRSqXpYEd1p2bMKngZKZz-mGZOshv%3D3Os1WcdscvAh5dtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Basic lock down

[Lee Armstrong]

I have my BBB flashed onto the eMMC and it is feasible for someone to boot from 
the SD Card and/or use the serial debug cable to gain access. 

What methods if any have people used to prevent some access?

-- 
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/936edd31-24a8-4340-8d46-4b0b0acba746%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Problem with eeprom of beaglebone black in my custom board

[masoud hajian]

Thanks Robert, that was great help. Now everything works well.

Regards,
Masoud



On Monday, May 2, 2016 at 8:07:45 AM UTC+4:30, RobertCNelson wrote:
>
>
>
> On Sun, May 1, 2016 at 10:23 PM, masoud hajian  > wrote:
>
>> Dear Robert,
>>
>> Thanks for you reply. The board is the same as beaglebone black without 
>> HDMI part. I used DDR3 but about your question which is BBB clone and BBW 
>> .. I do not know, I am quiet new in this area. Please tell me more if it 
>> possible. thanks.
>>
>
> Okay, since it's a beaglebone black clone with ddr3 you can use this:
>
>
> https://rcn-ee.net/rootfs/bb.org/testing/2016-05-01/console/a335-eeprom-debian-8.4-console-armhf-2016-05-01-2gb.img.xz
>
>
> https://rcn-ee.net/rootfs/bb.org/testing/2016-05-01/console/a335-eeprom-debian-8.4-console-armhf-2016-05-01-2gb.bmap
>
> Just dd/bmaptool it to a microSD card..
>
> GND the wp of the board eeprom..
>
> Boot the board, that image will program a default bbb eeprom..
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/53849970-524d-4f76-a5be-cbe70f975d49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Maxim Codec and BBB a different way.

[Rick Mann]

I agree. I've been trying to get a simple audio codec to work for over a year. 
It worked in 3.1.x, but now in 4.4.x it's marginal, at best (one channel works, 
not the other). I've been a bit lazy to see what the working 3.1.x version had 
different.

But, it's really complicated, very poorly documented, and the people would be 
able to clear it up either aren't on the lists (beaglebone and alsa), or don't 
care to answer.

> On May 2, 2016, at 00:05 , J dog  wrote:
> 
>Many including myself don't understand all  the complexity's of the way 
> the alsa-soc is developed.  And only a few engineers really have the grasp of 
> it.   Its so complex that T.I. themselves said mixing I2C and I2S into the 
> same code bundle makes it unnecessarily hard to develop a routine for each 
> soc board and each codec.   Here I will state some of the things as I 
> understand happen in alsa-soc.
> Alsa states,  there should a definition for each platform,  a definition for 
> each codec, and oddly something called the machine which is how they 
> intercommunicate I believe.
> What this means is for each platform, such as  A beaglebone black and a  
> beaglebone xm, the code could be different.  On top of that you then have to 
> have definitions for each codec.   So just because you have definitions for a 
> codec from a codec maker,  it doesn't mean your gonna compile that into the 
> kernel and walla!  your platform is now talking to the codec, its just not 
> that simple.  All this was done to combine i2c and i2s specifics for each 
> codec / platform to work from one package. 
> But after looking at this and realizing I was on the short end of a long 
> stick and finding a programmer that could even understand this stuff,  It 
> became evident that I2C was the villain like T.I. said.   Looking at the 
> disadvantages besides the complexity,  what happens in this prescribed 
> platform, codec, machine we find
> I2C being a timed command and response protocol uses wires completely 
> different than i2s, and even a different clock.
> I2S is only audio, it knows nothing but sending and receiving audio packets, 
> it doesn't care to whom and whatever codec is on the other end and as long as 
> it works with the same timings should work just fine. What happens if a I2C 
> command hangs in the middle of the routine to send I2S signals?.   audio 
> drops and possibly worse. A badly coded alsa-soc package can play hell not 
> only on audio, but may cause kernel dumps and who knows what else.
> I2S routines should be free from any hindrance,  let the kernel handle this 
> because its a very timing critical task.
> I2C commands though should occur from user space, they aren't so timing 
> critical and if from user space an i2c send / response sequence hangs, the 
> kernel / i2s routines probably wont even care.
> I2C from user space has the advantage of enhanced command error checking and 
> being able to be written in many languages that have access to i2c calls, 
> such as python, c++, nodejs and golang.
> 
> In this regard, an i2s driver with configurable parameters could be written 
> for every soc platform, and only once!  And an i2c routine can be universal 
> on all soc-platforms if the hooks to the actual pins are abstracted.I 
> will be presenting this thesis to the ALSA consortium at a future date.  
> 
> Jay Steele
> 
> 
> 
> On Sunday, May 1, 2016 at 11:24:06 PM UTC-7, J dog wrote:
> I am updating our project page for an advanced remotely controlled audio 
> system using the BBB and a Maxim Codec 98089.   We use a different method for 
> alsa-soc than most. Our DTB driver only uses I2S and no I2C control mechanism 
> is included in it. We think this makes the I2S routine cleaner and less error 
> prone.  We then use FTDI over USB to send our commands to the codec.  We will 
> be releasing the driver to the BBB community in a few days.  But you can 
> learn a lot of what we are doing now at our project page. 
> Perhaps as other developers learn more, alsa-soc may one day only need 
> platform specifics and allow any I2S codec to be used and the only thing one 
> needs to change are routines that call I2C commands or in our example FTDI 
> commands from user space.
> 
> https://sites.google.com/site/hdpoint1/home
> 
> Jay
> 
> -- 
> 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/8864cd4d-e244-41dd-acb5-52d8e967ba62%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
Rick Mann
rm...@latencyzero.com


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed 

[beagleboard] Re: Maxim Codec and BBB a different way.

[J dog]

   Many including myself don't understand all  the complexity's of the way 
the alsa-soc is developed.  And only a few engineers really have the grasp 
of it.   Its so complex that T.I. themselves said mixing I2C and I2S into 
the same code bundle makes it unnecessarily hard to develop a routine for 
each soc board and each codec.   Here I will state some of the things as I 
understand happen in alsa-soc.
Alsa states,  there should a definition for each platform,  a definition 
for each codec, and oddly something called the machine which is how they 
intercommunicate I believe.
What this means is for each platform, such as  A beaglebone black and a 
 beaglebone xm, the code could be different.  On top of that you then have 
to have definitions for each codec.   So just because you have definitions 
for a codec from a codec maker,  it doesn't mean your gonna compile that 
into the kernel and walla!  your platform is now talking to the codec, its 
just not that simple.  All this was done to combine i2c and i2s specifics 
for each codec / platform to work from one package.  
But after looking at this and realizing I was on the short end of a long 
stick and finding a programmer that could even understand this stuff,  It 
became evident that I2C was the villain like T.I. said.   Looking at the 
disadvantages besides the complexity,  what happens in this prescribed 
platform, codec, machine we find
I2C being a timed command and response protocol uses wires 
completely different than i2s, and even a different clock. 
I2S is only audio, it knows nothing but sending and receiving audio 
packets, it doesn't care to whom and whatever codec is on the other end 
and as long as it works with the same timings should work just fine. What 
happens if a I2C command hangs in the middle of the routine to send I2S 
signals?.   audio drops and possibly worse. A badly coded alsa-soc package 
can play hell not only on audio, but may cause kernel dumps and who knows 
what else.
I2S routines should be free from any hindrance,  let the kernel handle this 
because its a very timing critical task. 
I2C commands though should occur from user space, they aren't so timing 
critical and if from user space an i2c send / response sequence hangs, the 
kernel / i2s routines probably wont even care. 
I2C from user space has the advantage of enhanced command error checking 
and being able to be written in many languages that have access to i2c 
calls, such as python, c++, nodejs and golang. 

In this regard, an i2s driver with configurable parameters could be written 
for every soc platform, and only once!  And an i2c routine can be universal 
on all soc-platforms if the hooks to the actual pins are abstracted.I 
will be presenting this thesis to the ALSA consortium at a future date.   

Jay Steele



On Sunday, May 1, 2016 at 11:24:06 PM UTC-7, J dog wrote:

> I am updating our project page for an advanced remotely controlled audio 
> system using the BBB and a Maxim Codec 98089.   We use a different method 
> for alsa-soc than most. Our DTB driver only uses I2S and no I2C control 
> mechanism is included in it. We think this makes the I2S routine cleaner 
> and less error prone.  We then use FTDI over USB to send our commands to 
> the codec.  We will be releasing the driver to the BBB community in a few 
> days.  But you can learn a lot of what we are doing now at our project 
> page. 
> Perhaps as other developers learn more, alsa-soc may one day only need 
> platform specifics and allow any I2S codec to be used and the only thing 
> one needs to change are routines that call I2C commands or in our example 
> FTDI commands from user space. 
>
> https://sites.google.com/site/hdpoint1/home
>
> Jay
>

-- 
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/8864cd4d-e244-41dd-acb5-52d8e967ba62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Maxim Codec and BBB a different way.

[J dog]

I am updating our project page for an advanced remotely controlled audio 
system using the BBB and a Maxim Codec 98089.   We use a different method 
for alsa-soc than most. Our DTB driver only uses I2S and no I2C control 
mechanism is included in it. We think this makes the I2S routine cleaner 
and less error prone.  We then use FTDI over USB to send our commands to 
the codec.  We will be releasing the driver to the BBB community in a few 
days.  But you can learn a lot of what we are doing now at our project 
page. 
Perhaps as other developers learn more, alsa-soc may one day only need 
platform specifics and allow any I2S codec to be used and the only thing 
one needs to change are routines that call I2C commands or in our example 
FTDI commands from user space. 

https://sites.google.com/site/hdpoint1/home

Jay

-- 
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/84f41696-2c28-4148-b318-425eb0da903e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Black + Audio codec TLV320AIC3106

[J dog]

Something of this nature should work on the command line.

amixer -c sset 'Left Line Mixer LLOUT' on # Line out Left enable
amixer -c  sset 'Right Line Mixer RLOUT' on# Line out Right 
enable
amixer -c  sset 'Line DAC' 90  # Adjust Line out 
volume

This is a guess.  But if you want to know more check out this page. 

http://processors.wiki.ti.com/index.php/Linux_Core_Audio_User%27s_Guide


Jay

On Wednesday, March 9, 2016 at 8:52:52 PM UTC-8, Dileep D R wrote:

> Hi,
>
>  Below is the dtb configuration for audio routing,
>
>
> sound {
>compatible = "ti,da830-evm-audio";
>ti,model = "DA830 EVM";
>ti,audio-codec = <>;
>ti,mcasp-controller = <>;
>ti,codec-clock-rate = <1200>;
>   ti,audio-routing =
> "Headphone Jack", "HPLOUT",
> "Headphone Jack", "HPROUT",
> "Line Out", "LLOUT",
> "Line Out", "RLOUT",
> "LINE1L", "Line In",
> "LINE1R", "Line In";
> };
>
> I am able to hear audio on headphone when I play a wav file with aplay. 
> But I also want output on*Line out* how to achieve the routing?
>
>
> Thanks,
>
> Dileep
>

-- 
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/a5c06b02-6483-4fe9-9024-a4564af33070%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.