Re: [beagleboard] How susceptible is BeagleBone to the Mirai software?

2016-10-27 Thread Jason Kridner 
And Cloud9 IDE which runs as root. 

I'm looking if any security grad student wants to do a study on how to secure a 
BeagleBone and keep the ease of use. Just leaving a conference with the guys 
leading some of the analysis of Mirai out of U of M and I hope they'll take the 
challenge. 

> On Oct 27, 2016, at 7:25 PM, Robert Nelson  wrote:
> 
>> On Thu, Oct 27, 2016 at 1:12 PM, Josiah Yoder  wrote:
>> I teach a real-time systems class where students use Beaglebone over the
>> network.  Generally, we are behind  a protected firewall, but sometimes the
>> students want to debug on other parts of the campus.
>> 
>> By default, one can access the root account without a password.  If my
>> students put such a BeagleBone on a network where the IP is externally
>> visible, is it likely that the BeagleBone will become infected by the
>> open-source botnet software Mirai?
>> 
>> I guess it's a moot point -- the root password should be changed before
>> attaching the BeagleBone to a public network anyway!
> 
> At-least run:
> 
> cd /opt/scripts/un-tweak-image/
> 
> sudo ./debian-re-secure-root-ssh.sh
> 
> and it'll set a root password and disable "PermitEmptyPasswords"
> sshd_config option..
> 
> and remove "bonescript", you can just disable disable the two
> bonescript system service files..
> 
> 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/CAOCHtYiwk2M3T%2BR8uiQNa8sxzNoHxkdV3c4eBPimDhxnSn-_%2Bw%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/91221EFA-363E-42FC-8004-3922735FEF8D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Funtoo on Beagleboard X15

2016-10-27 Thread Catudal Michel 
I have created a funtoo for the Beagleboard X15. I can boot it and will be 
adding to it. The basic without xorg with full internet support boots in 
about 3.4 seconds.
I use the u-boot and Linux kernel from the latest TI SDK release. I use it 
on a Rev A2 board but it will also work on a Rev B1 board.
Funtoo is a source based Linux distribution similar to gentoo. So far I am 
not aware of any Gentoo or Funtoo support for this board. I plan to add 
support for the Beaglebone boards but that will come later.

If anyone is interested to work with me on this let me know.


Michel

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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/ad6b38ab-72da-43f4-8ae4-718fdebb2306%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How susceptible is BeagleBone to the Mirai software?

2016-10-27 Thread Robert Nelson 
On Thu, Oct 27, 2016 at 1:12 PM, Josiah Yoder  wrote:
> I teach a real-time systems class where students use Beaglebone over the
> network.  Generally, we are behind  a protected firewall, but sometimes the
> students want to debug on other parts of the campus.
>
> By default, one can access the root account without a password.  If my
> students put such a BeagleBone on a network where the IP is externally
> visible, is it likely that the BeagleBone will become infected by the
> open-source botnet software Mirai?
>
> I guess it's a moot point -- the root password should be changed before
> attaching the BeagleBone to a public network anyway!

At-least run:

cd /opt/scripts/un-tweak-image/

sudo ./debian-re-secure-root-ssh.sh

and it'll set a root password and disable "PermitEmptyPasswords"
sshd_config option..

and remove "bonescript", you can just disable disable the two
bonescript system service files..

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/CAOCHtYiwk2M3T%2BR8uiQNa8sxzNoHxkdV3c4eBPimDhxnSn-_%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How susceptible is BeagleBone to the Mirai software?

2016-10-27 Thread Charles Steinkuehler 
On 10/27/2016 1:12 PM, Josiah Yoder wrote:
> I teach a real-time systems class where students use Beaglebone over the 
> network.  Generally, we are behind  a protected firewall, but sometimes the 
> students want to debug on other parts of the campus.
> 
> By default, one can access the root account without a password.  If my 
> students 
> put such a BeagleBone on a network where the IP is externally visible, is it 
> likely that the BeagleBone will become infected by the open-source botnet 
> software Mirai?
> 
> I guess it's a moot point -- the root password should be changed before 
> attaching the BeagleBone to a public network anyway!

At the very least, you need to set a root password, set a password for
the default user, and disable the "no password" sudo access.

I would also recommend reviewing the open network ports and disabling
anything you don't need to use or that isn't secure.  You probably
don't want things like xrdp and xvnc visible on the raw internet.

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/898a16f2-324e-d6f1-8934-8e59a4bbbea5%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How susceptible is BeagleBone to the Mirai software?

2016-10-27 Thread Josiah Yoder 
I teach a real-time systems class where students use Beaglebone over the 
network.  Generally, we are behind  a protected firewall, but sometimes the 
students want to debug on other parts of the campus.

By default, one can access the root account without a password.  If my 
students put such a BeagleBone on a network where the IP is externally 
visible, is it likely that the BeagleBone will become infected by the 
open-source botnet software Mirai?

I guess it's a moot point -- the root password should be changed before 
attaching the BeagleBone to a public network anyway!

Josiah

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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/a7ba9a6a-b1b8-4910-8d26-84e54a9f1e64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Understanding and reducing boot time

2016-10-27 Thread 'Mark Lazarewicz' via BeagleBoard 
Sitara Linux Training: Boot Time Reduction - Texas Instruments Wiki
  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
Sitara Linux Training: Boot Time Reduction - Texas Instruments Wiki
   |   |

  |

  |

 


  From: 'Mark Lazarewicz' via BeagleBoard 
 To: "beagleboard@googlegroups.com" ; 
Jean-Sebastien Stoezel ; BeagleBoard 
 
 Sent: Thursday, October 27, 2016 3:56 PM
 Subject: Re: [beagleboard] Re: Understanding and reducing boot time
   
I used Google beagleboard boot time  I'd help but my focus is barebone or RTOS 
embedded systems not linux. From memory I think the biggest reduction is 
obtained from loading linux. Try that search and take a look at the results and 
if still don't see anything useful I'll post links. What kind of total boot 
time are your requirements ?

Sent from Yahoo Mail on Android 
 
 On Thu, Oct 27, 2016 at 8:41 AM, Jean-Sebastien Stoezel 
wrote:  Lazarman:
To answer your question, yes I have used the Google search in the group and I 
did not find something that applied directly to my questions:- The information 
I found on how to disable the timeout where either to vague for me to figure 
out, or did not seem to apply to the configuration on my board,- I did not find 
anything related to customizing the bootup, apart from enabling/disabling capes 
manually in uEnv.txt. My question is related to forcing states in the bootup 
scripts rather than automatic detection
Now since you seem to have written a tutorial on how to speed up boot time, and 
since this did not show up in the search results, would it be possible for you 
to link directly to it? This I feel, would be a useful piece of information to 
this thread.
Regards,JS

On Tuesday, October 25, 2016 at 11:40:50 AM UTC-5, Jean-Sebastien Stoezel wrote:
Hi:
I am running a Beagle Bone with a custom cape and I am looking for ways to 
reduce its boot time. The cape will always be the same and so I'd like to see 
what it is I can change to reduce or completely remove custom auto detection 
scripts.As of now, the board boots in 18s, 8s are spent in the kernel, 10s are 
spent in user space.
I have seen numbers out stating that the kernel can boot in less than 2s. I'd 
be interested to know how this is possible. I am aware of a timeout being used 
in the kernel, though I am not sure how to disable this (using 
4.1.33-bone-rt-r24).
Currently generic-board-startup.service seems to be the service that takes the 
longest to complete. Looking at what it does, it seems to be invoking 
am335x_evm.h.sh. I am wondering if I could disable anything related to 
detecting capes (including trying to read the eeprom). At this time I can see 
lines 30 to 55 in the scripts being related to eeprom flashing/reading, though 
I am not sure this is targetting the cape's eeprom.
In general, how would I go about disabling auto detection of capes? Would I 
need to edit these scripts? Or is there a cleaner way to disable features by 
editing a config file?
Regards,JS

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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/a8ddaef0-61e9-461a-9f69-a02f9b3a0e82%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/374321267.97403.1477601774823%40mail.yahoo.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/1951552855.158457.1477610371734%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Understanding and reducing boot time

2016-10-27 Thread 'Mark Lazarewicz' via BeagleBoard 
I used Google beagleboard boot time  I'd help but my focus is barebone or RTOS 
embedded systems not linux. From memory I think the biggest reduction is 
obtained from loading linux. Try that search and take a look at the results and 
if still don't see anything useful I'll post links. What kind of total boot 
time are your requirements ?

Sent from Yahoo Mail on Android 
 
  On Thu, Oct 27, 2016 at 8:41 AM, Jean-Sebastien Stoezel 
wrote:   Lazarman:
To answer your question, yes I have used the Google search in the group and I 
did not find something that applied directly to my questions:- The information 
I found on how to disable the timeout where either to vague for me to figure 
out, or did not seem to apply to the configuration on my board,- I did not find 
anything related to customizing the bootup, apart from enabling/disabling capes 
manually in uEnv.txt. My question is related to forcing states in the bootup 
scripts rather than automatic detection
Now since you seem to have written a tutorial on how to speed up boot time, and 
since this did not show up in the search results, would it be possible for you 
to link directly to it? This I feel, would be a useful piece of information to 
this thread.
Regards,JS

On Tuesday, October 25, 2016 at 11:40:50 AM UTC-5, Jean-Sebastien Stoezel wrote:
Hi:
I am running a Beagle Bone with a custom cape and I am looking for ways to 
reduce its boot time. The cape will always be the same and so I'd like to see 
what it is I can change to reduce or completely remove custom auto detection 
scripts.As of now, the board boots in 18s, 8s are spent in the kernel, 10s are 
spent in user space.
I have seen numbers out stating that the kernel can boot in less than 2s. I'd 
be interested to know how this is possible. I am aware of a timeout being used 
in the kernel, though I am not sure how to disable this (using 
4.1.33-bone-rt-r24).
Currently generic-board-startup.service seems to be the service that takes the 
longest to complete. Looking at what it does, it seems to be invoking 
am335x_evm.h.sh. I am wondering if I could disable anything related to 
detecting capes (including trying to read the eeprom). At this time I can see 
lines 30 to 55 in the scripts being related to eeprom flashing/reading, though 
I am not sure this is targetting the cape's eeprom.
In general, how would I go about disabling auto detection of capes? Would I 
need to edit these scripts? Or is there a cleaner way to disable features by 
editing a config file?
Regards,JS



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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/a8ddaef0-61e9-461a-9f69-a02f9b3a0e82%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/374321267.97403.1477601774823%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] bbx15: v4.4.x + OpenCL

2016-10-27 Thread Robert Nelson 
Hey Everyone,

Finally got OpenCL working again on v4.4.x, lots of fun "dkms" module
issues, so ripped all those out..

mkbian@beaglebone:/usr/share/ti/examples/opencl/float_compute$ sudo
modprobe cmem
This example computes y[i] = M[i] * x[i] + C on single precision
floating point arrays of size 2097152
- Computation on the ARM is parallelized across the A15s using OpenMP.
- Computation on the DSP is performed by dispatching an OpenCL NDRange
kernel across the compute units (C66x cores) in the compute device.

Running.

Average across 5 runs:
ARM (2 OpenMP threads) : 0.008669 secs
DSP (OpenCL NDRange kernel): 0.007781 secs
OpenCL-DSP speedup : 1.114124

For more information on:

This Sunday's lxqt image will have all the fun bits..

For older images do this:

sudo apt-get update
sudo apt-get upgrade

sudo apt-get remove dkms --purge  #get rid of dkms/etc..

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh
sudo reboot

cd /usr/share/ti/examples/opencl/float_compute/
sudo make
sudo modprobe cmemk
sudo ./float_compute

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

Re: [beagleboard] What is the latest BBGW image?

2016-10-27 Thread Danko Miocevic 
Hi,

I got it working! I just installed the bb-wl18xx-firmware package and then 
the firmware-ti-connectivity package. But instead of using the one in 
debian repo I used the one from https://rcn-ee.net.
 
It worked like a charm!

I did a bb-wl18xx-wlan0, then a reboot and then installed the wireless 
network tools packages.
Then I did a ifconfig to bring wlan0 up and after that just iwlist to list 
all the networks.

Regards,
Danko

El miércoles, 26 de octubre de 2016, 22:16:30 (UTC-3), Danko Miocevic 
escribió:
>
> Hi,
> First of all I would like to thank Robert Nelson too for all the hard work!
>
> I've been trying to use the wlan0 like Guillaume Biton did. 
> This is what I tried:
>
> - First I downloaded the same build (2016-10-23) and downloaded 
> the bb-wl18xx-firmware debian package. Installed it and get the same 
> results:
>
> [  105.702806] wlcore: ERROR could not get firmware 
> ti-connectivity/wl18xx-fw-4.bin: -2
> [  106.065979] wlcore: ERROR could not get firmware 
> ti-connectivity/wl18xx-fw-4.bin: -2
> [  106.429990] wlcore: ERROR could not get firmware 
> ti-connectivity/wl18xx-fw-4.bin: -2
> [  106.441032] wlcore: ERROR firmware boot failed despite 3 retries
>
> - I also tried adding the firmware-ti-connectivity package with no luck 
> also (same error).
> - I tried to compile the next snapshot with your modifications in a VM but 
> I get:
>
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped (This 
> is a known error from qemu).
>
> I am writing to check wether the next snapshot will work just by adding 
> those packages or not. 
> On the other hand I would like to help with the BBGW and the wlan0 
> connections. 
> How can I give you a hand? Do you use a VM to build the snapshots or do 
> you run them in your computer?
>
> Regards,
> Danko
>
> El martes, 25 de octubre de 2016, 13:58:28 (UTC-3), RobertCNelson escribió:
>>
>> On Tue, Oct 25, 2016 at 11:54 AM, Guillaume Biton 
>>  wrote: 
>> > Hi, 
>> > 
>> > I downloaded monday's image (2016-10-23). 
>> > With a ifconfig -a I now see a "wlan0" interface but cannot enable it. 
>> > 
>> > If I add the following to my etc/network/interfaces : 
>> > allow-hotplug wlan0 
>> > iface wlan0 inet dhcp 
>> > 
>> > I get a : 
>> > [   27.017962] wlcore: ERROR could not get firmware 
>> > ti-connectivity/wl18xx-fw-4.bin: -2 
>> > [   27.377954] wlcore: ERROR could not get firmware 
>> > ti-connectivity/wl18xx-fw-4.bin: -2 
>> > [   27.737961] wlcore: ERROR could not get firmware 
>> > ti-connectivity/wl18xx-fw-4.bin: -2 
>> > [   27.748991] wlcore: ERROR firmware boot failed despite 3 retries 
>> > 
>> > On boot. 
>> > 
>> > I did not understand whether or not you could include the driver to the 
>> last 
>> > image (you said something about patching bluez) ? 
>> > 
>> > Anyway : thank you so much for your amazing work and reactivity ! 
>>
>> Yeah, i have it setup for the next snapshot.. 
>>
>>
>> https://github.com/RobertCNelson/omap-image-builder/commit/127a6fb6d0c7a3b08bcc12ec619c814aac9e2241
>>  
>>
>> 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/2fea1496-a2db-4afa-963f-dd71cb68bb6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Dallas 1-Wire BeagleBone Black

2016-10-27 Thread William Hermans 
Yeah, I guess I read that wrong. Isn't fixed point fun ?!

On Thu, Oct 27, 2016 at 7:44 AM, Mark A. Yoder 
wrote:

> So it was a bit unclear, I only teach for a living :->.  I've fixed it a
> bit.
>
> This must be an interesting topic.  Over 5000 views in this group and 100
> views of the eLinux page.
>
> --Mark
>
> On Thursday, October 27, 2016 at 10:38:58 AM UTC-4, Jason Kridner wrote:
>>
>>
>>
>> On Oct 26, 2016, at 3:20 PM, William Hermans  wrote:
>>
>> HI Mark,
>>
>> So here: http://elinux.org/EBC_Exercise_31_Dallas_1-Wire#Reading_the_
>> DS12B20
>>
>> Shouldn't
>>
>> The *t=24437* is the temperature in C times 1000. Warm up the probe and
>>> see what happens to the temp.
>>>
>>>
>> I believe this is stated properly, but could be confusing.
>>
>> Be:
>>
>> The *t=24437* is the temperature in C times .001. Warm up the probe and
>>> see what happens to the temp.
>>>
>>
>> ?
>>
>>
>> Perhaps you mean:
>> Given t=24437, you can determine the temperature in C by multiplying t by
>> .001. Warm up the probe and see what happens to the temp.
>>
>> You could also say by dividing by 1000. Mark's language was right because
>> he was describing how t is derived from the temperature and not the other
>> way around.
>>
>>
>> I do like your courses though. Really easy for someone like me , who has
>> yet had experience with one-wire devices.
>>
>> On Wed, Oct 26, 2016 at 7:23 AM, Mark A. Yoder 
>> wrote:
>>
>>> I've just posted[1] updated instructions on how to use Dallas 1-wire
>>> devices on the Bone.  I'm running:
>>> bone$ *uname -a*
>>> Linux yoder-debian-bone 4.4.21-ti-r47 #1 SMP Fri Sep 23 22:23:02 UTC
>>> 2016 armv7l GNU/Linux
>>> bone$ *cat /ID.txt*
>>> BeagleBoard.org Debian Image 2016-08-28
>>>
>>> The instructions show how to deconfigure  P9_12 so the 1-wire driver can
>>> run on it.
>>>
>>> --Mark
>>>
>>> [1] http://elinux.org/EBC_Exercise_31_Dallas_1-Wire
>>>
>>> On Sunday, January 19, 2014 at 8:42:49 PM UTC-5, godsf...@gmail.com
>>> wrote:

 Can you post a photo of how you have them wired please?

 On Wednesday, December 4, 2013 8:51:26 AM UTC-5, Doug Edey wrote:
>
> I've got 3 DS18B20 sensors on my bus at the moment, providing you've
> got the sensors running in non-parasitic mode, I think you'll be fine.
>
> On Tuesday, December 3, 2013 8:13:31 PM UTC-5, lorena...@gmail.com
> wrote:
>>
>> Thinking of replacing the dedicated microcontroller that runs my
>> house with a BBB. Being able to read the existing 1-Wire network will be
>> critical. Currently have 12 18B20 sensors on one bus, need more. Can the
>> kernel module described here actually address and read multiple sensors 
>> on
>> the same bus? Can it search and retrieve addresses from unknown sensors?
>>
>> I see people selling 8-port capes, as if maybe this is a simple one
>> device per bus routine...  Wouldn't help me!
>>
>> As for the "considerations" of long buses, yes there was a learning
>> curve. I have both active pull-up and active pull-down, with careful
>> source-end termination. All cable is CAT-5, and all sensors are within 1m
>> of a single linear topology installation. In several cases the bus goes 
>> out
>> one pair of the CAT-5 to a distant sensor and comes back on another pair 
>> of
>> the same cable to continue to the next destination. Branching.in a star
>> fashion is death to 1-Wire. My current system works, reliably controlling
>> serious solar hot water and outdoor wood boiler operation that could blow
>> off expensive antifreeze fluid (a huge hassle to recharge) if anything
>> overheated.
>>
>> Great long-bus reference:
>> http://www.1wire.org/Files/Articles/1-Wire-Design%20Guide%20v1.0.pdf
>>
> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because 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/ms
>>> gid/beagleboard/6a937fdb-7316-48b0-8b84-543757958c8c%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...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/beagleboard/CALHSORoZHnv1PArG9zyCfV36esCb8T_%2BtJ-
>> 1zy7amx8TMOQocA%40mail.gmail.com
>>

Re: [beagleboard] Beaglebone Green and PRU "Programmable Real-Time Unit" Interface to ADC using RemoteProc and RPMsg

2016-10-27 Thread William Hermans 
Jason,

Well, my point was that it would be nice to have a list of required files
for a PRU / remoteproc project. Something that describes the minimal
required files, and what each file purpose is.

On Thu, Oct 27, 2016 at 7:54 AM, Jason Kridner 
wrote:

> http://processors.wiki.ti.com/index.php/Linker_Command_File_Primer
> On Thu, Oct 27, 2016 at 7:02 AM Greg  wrote:
>
>> Hi William, yes those files are kind of mysterious.  Some are related to
>> the C compiler/linker, and the others are related to remoteproc.  I used
>> the examples from the PRU Support Package as a template.  The Makefile
>> (which is really simple) has to be aware of these files.
>>
>> It was pretty much plug-and-chug, as I followed the example patterns and
>> there were no issues.  It would be good to understand them better,
>> especially later if I start tweaking the kernel modules or creating new
>> ones.
>>
>> I'm probably need to ask the folks at TI for some comments on the
>> functions of these files, and then write it up in an expanded Remoteproc
>> chapter.
>>
>> Regards,
>> Greg
>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because 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/18dc22db-50bb-4a66-af58-4e831659c141%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/CA%2BT6QPmQJ9vXS_-7FMNp3WZT2JtZJAODCQgiuDw2F0LjC
> vricQ%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/CALHSORo_AXCBZL%2BNciwL47Sfz%2B%3DJstzriOOorjh62EZbAzb9oQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Where/how do I get the latest apt key for debian wheezy updates?

2016-10-27 Thread Robert Nelson 
On Thu, Oct 27, 2016 at 10:29 AM, Chris Green  wrote:
> Robert Nelson  wrote:
>> On Tue, Oct 25, 2016 at 2:41 PM, Chris Green  wrote:
>> > I am trying to get my rather remote (and infrequently updated) BBB
>> > running Debian Wheezy up to date.  It's complaining that the key for
>> > the Debian Wheezy BBB repository is out of date, where can I get the latest
>> > key?
>> >
>> > W: A error occurred during the signature verification. The repository
>> > is not updated and the previous index files will be used. GPG error:
>> > http://debian.beagleboard.org wheezy-bbb Release: The following
>> > signatures were invalid: KEYEXPIRED 1418840246 KEYEXPIRED 1418840304
>> > KEYEXPIRED 1418840246 KEYEXPIRED 1418840246 KEYEXPIRED 1418840304
>> >
>> > W: Failed to fetch
>> > http://debian.beagleboard.org/packages/dists/wheezy-bbb/Release
>>
>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#W:_GPG_error:_http:.2F.2Fdebian.beagleboard.org_wheezy-bbb
>>
>>
> OK, thanks Robert, it's just a matter of removing that repository from
> the apt list then.
>
> Is this because BBB has become more 'standard' and thus gets
> everything from the main ARM repository?

Nah, we just didn't have the signing key to push updates to it. ;)

I've copied all useful deb packages that were provided by
debian.beagleboard.org  into repos.rcn-ee.net

you can follow:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-05-14_GPG_error:_Optional_enable:_http:.2F.2Frepos.rcn-ee.com.2F

to update that old 2014-05-14 image..

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/CAOCHtYgDwiUL1VmpzLE6ULsrw9oNLHg%2B2M8MMgM9fSG_%2BMi%2B0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Where/how do I get the latest apt key for debian wheezy updates?

2016-10-27 Thread Chris Green 
Robert Nelson  wrote:
> On Tue, Oct 25, 2016 at 2:41 PM, Chris Green  wrote:
> > I am trying to get my rather remote (and infrequently updated) BBB
> > running Debian Wheezy up to date.  It's complaining that the key for
> > the Debian Wheezy BBB repository is out of date, where can I get the latest
> > key?
> >
> > W: A error occurred during the signature verification. The repository
> > is not updated and the previous index files will be used. GPG error:
> > http://debian.beagleboard.org wheezy-bbb Release: The following
> > signatures were invalid: KEYEXPIRED 1418840246 KEYEXPIRED 1418840304
> > KEYEXPIRED 1418840246 KEYEXPIRED 1418840246 KEYEXPIRED 1418840304
> >
> > W: Failed to fetch
> > http://debian.beagleboard.org/packages/dists/wheezy-bbb/Release
> 
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#W:_GPG_error:_http:.2F.2Fdebian.beagleboard.org_wheezy-bbb
>  
> 
> 
OK, thanks Robert, it's just a matter of removing that repository from
the apt list then.

Is this because BBB has become more 'standard' and thus gets
everything from the main ARM repository?

-- 
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/t3j9ed-lvj.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] network configuration at start up is failing

2016-10-27 Thread oswald . lackner 
Hallo everyone,

My BBB seems NOT to be able to assign network properties at startup.

Linux version 4.4.23-ti-r51 (root@a2-imx6q-wandboard-2gb) (gcc version 
4.9.2 (Debian 4.9.2-10) ) #1 SMP Mon Oct 3 22:56:05 UTC 2016
IMG: BBB-eMMC-flasher-debian-8.6-console-armhf-2016-10-06-2gb

My configuration (i have deactivated renaming over 
udev/rules.d/70-persistent-net.rules)

#auto wlxe46f13296891
#iface wlxe46f13296891 inet static
auto wlan0
iface wlan0 inet static
address 192.168.4.1
network 192.168.4.0
netmask 255.255.255.0
broadcast 192.168.4.255
hostapd /etc/hostapd/hostapd.conf


When restarting network service it works successfully: ifconfig



wlan0 Link encap:Ethernet  HWaddr e4:6f:13:29:68:91
  inet addr:192.168.4.1  Bcast:192.168.4.255  Mask:255.255.255.0
  UP BROADCAST MULTICAST DYNAMIC  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


According to journalctl WLAN stick is found correctly by kernel


~~~
May 21 22:31:30 arm kernel: usb 1-1: new high-speed USB device number 2 
using musb-hdrc
May 21 22:31:30 arm kernel: usb 1-1: New USB device found, idVendor=2001, 
idProduct=3308
May 21 22:31:30 arm kernel: usb 1-1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3
May 21 22:31:30 arm kernel: usb 1-1: Product: 802.11n WLAN Adapter
May 21 22:31:30 arm kernel: usb 1-1: Manufacturer: Realtek
May 21 22:31:30 arm kernel: usb 1-1: SerialNumber: 00e04c01
~~~

Then systemd ist starting everything else and when its about to start the 
network interfaces 

~~~  
Oct 25 09:12:25 arm ifup[582]: Cannot find device "wlan0"
Oct 25 09:12:25 arm ifup[582]: Failed to bring up wlan0.
Oct 25 09:12:25 arm systemd[1]: Starting LSB: Start busybox udhcpd at boot 
time...
Oct 25 09:12:25 arm systemd[1]: Starting LSB: oFono Mobile Telephony 
Daemon...
Oct 25 09:12:26 arm systemd[1]: Started BB WL18xx wlan0 Service.


Oct 25 09:12:36 arm kernel: omap_rng 4831.rng: OMAP Random Number 
Generator ver. 20
Oct 25 09:12:37 arm kernel: rtl8192cu: Chip version 0x10
Oct 25 09:12:37 arm kernel: omap-aes 5350.aes: OMAP AES hw accel rev: 
3.2
Oct 25 09:12:37 arm kernel: omap-sham 5310.sham: hw accel on OMAP rev 
4.3
Oct 25 09:12:38 arm kernel: rtl8192cu: MAC address: e4:6f:13:29:68:91
Oct 25 09:12:38 arm kernel: rtl8192cu: Board Type 0
Oct 25 09:12:38 arm kernel: rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 
1
Oct 25 09:12:38 arm kernel: rtl8192cu: Loading firmware 
rtlwifi/rtl8192cufw_TMSC.bin
Oct 25 09:12:38 arm kernel: ieee80211 phy0: Selected rate control algorithm 
'rtl_rc'
Oct 25 09:12:38 arm connmand[799]: wlan0 {create} index 4 type 1 
Oct 25 09:12:38 arm connmand[799]: wlan0 {update} flags 4098 
Oct 25 09:12:38 arm connmand[799]: wlan0 {newlink} index 4 address 
E4:6F:13:29:68:91 mtu 1500
Oct 25 09:12:38 arm kernel: usbcore: registered new interface driver 
rtl8192cu
Oct 25 09:12:38 arm connmand[799]: wlan0 {newlink} index 4 operstate 2 

Oct 25 09:12:38 arm connmand[799]: Adding interface wlan0 [ wifi ]
~~
Oct 25 09:12:40 arm kernel: rtl8192cu: MAC auto ON okay!
Oct 25 09:12:40 arm kernel: rtl8192cu: Tx queue select: 0x05
Oct 25 09:12:41 arm kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not 
ready
Oct 25 09:12:41 arm systemd-udevd[605]: Process '/sbin/crda' failed with 
exit code 249.
Oct 25 09:12:41 arm connmand[799]: wlan0 {update} flags 36931 
Oct 25 09:12:41 arm connmand[799]: wlan0 {newlink} index 4 address 
E4:6F:13:29:68:91 mtu 1500
Oct 25 09:12:41 arm connmand[799]: wlan0 {newlink} index 4 operstate 0 

Oct 25 09:12:41 arm connmand[799]: wlan0 {update} flags 36867 
Oct 25 09:12:41 arm connmand[799]: wlan0 {newlink} index 4 address 
E4:6F:13:29:68:91 mtu 1500
Oct 25 09:12:41 arm connmand[799]: wlan0 {newlink} index 4 operstate 2 

Oct 25 09:12:41 arm connmand[799]: wlan0 {newlink} index 4 address 
E4:6F:13:29:68:91 mtu 1500
Oct 25 09:12:41 arm connmand[799]: wlan0 {newlink} index 4 operstate 2 

~~~
Oct 25 09:27:49 arm systemd[1]: Starting Raise network interfaces...
Oct 25 09:27:49 arm connmand[799]: wlan0 {add} address 192.168.4.1/24 label 
wlan0 family 2
Oct 25 09:27:49 arm avahi-daemon[744]: Joining mDNS multicast group on 
interface wlan0.IPv4 with address 192.168.4.1.
Oct 25 09:27:49 arm connmand[799]: wlan0 {add} route 192.168.4.0 gw 0.0.0.0 
scope 253 
Oct 25 09:27:49 arm avahi-daemon[744]: New relevant interface wlan0.IPv4 
for mDNS.
Oct 25 09:27:49 arm avahi-daemon[744]: Registering new address record for 
192.168.4.1 on wlan0.IPv4.


It somehow seems that i have to use connman for configuration, or is it 
still possible to configure it that way?
How can i configure connman correctly or where can i find a good source for 
information about connman.
google wasn't enough friend of my to find me a good source of complete ...


Thank you
Osw

Re: [beagleboard] Beaglebone Green and PRU "Programmable Real-Time Unit" Interface to ADC using RemoteProc and RPMsg

2016-10-27 Thread Jason Kridner 
http://processors.wiki.ti.com/index.php/Linker_Command_File_Primer
On Thu, Oct 27, 2016 at 7:02 AM Greg  wrote:

> Hi William, yes those files are kind of mysterious.  Some are related to
> the C compiler/linker, and the others are related to remoteproc.  I used
> the examples from the PRU Support Package as a template.  The Makefile
> (which is really simple) has to be aware of these files.
>
> It was pretty much plug-and-chug, as I followed the example patterns and
> there were no issues.  It would be good to understand them better,
> especially later if I start tweaking the kernel modules or creating new
> ones.
>
> I'm probably need to ask the folks at TI for some comments on the
> functions of these files, and then write it up in an expanded Remoteproc
> chapter.
>
> Regards,
> Greg
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because 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/18dc22db-50bb-4a66-af58-4e831659c141%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/CA%2BT6QPmQJ9vXS_-7FMNp3WZT2JtZJAODCQgiuDw2F0LjCvricQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Dallas 1-Wire BeagleBone Black

2016-10-27 Thread Mark A. Yoder 
So it was a bit unclear, I only teach for a living :->.  I've fixed it a 
bit.

This must be an interesting topic.  Over 5000 views in this group and 100 
views of the eLinux page.

--Mark

On Thursday, October 27, 2016 at 10:38:58 AM UTC-4, Jason Kridner wrote:
>
>
>
> On Oct 26, 2016, at 3:20 PM, William Hermans  > wrote:
>
> HI Mark,
>
> So here: 
> http://elinux.org/EBC_Exercise_31_Dallas_1-Wire#Reading_the_DS12B20
>
> Shouldn't
>
> The *t=24437* is the temperature in C times 1000. Warm up the probe and 
>> see what happens to the temp. 
>>
>>
> I believe this is stated properly, but could be confusing. 
>
> Be: 
>
> The *t=24437* is the temperature in C times .001. Warm up the probe and 
>> see what happens to the temp. 
>>
>
> ?
>
>
> Perhaps you mean:
> Given t=24437, you can determine the temperature in C by multiplying t by 
> .001. Warm up the probe and see what happens to the temp.
>
> You could also say by dividing by 1000. Mark's language was right because 
> he was describing how t is derived from the temperature and not the other 
> way around. 
>
>
> I do like your courses though. Really easy for someone like me , who has 
> yet had experience with one-wire devices.
>
> On Wed, Oct 26, 2016 at 7:23 AM, Mark A. Yoder  > wrote:
>
>> I've just posted[1] updated instructions on how to use Dallas 1-wire 
>> devices on the Bone.  I'm running:
>> bone$ *uname -a*
>> Linux yoder-debian-bone 4.4.21-ti-r47 #1 SMP Fri Sep 23 22:23:02 UTC 2016 
>> armv7l GNU/Linux
>> bone$ *cat /ID.txt* 
>> BeagleBoard.org Debian Image 2016-08-28
>>
>> The instructions show how to deconfigure  P9_12 so the 1-wire driver can 
>> run on it.
>>
>> --Mark
>>
>> [1] http://elinux.org/EBC_Exercise_31_Dallas_1-Wire
>>
>> On Sunday, January 19, 2014 at 8:42:49 PM UTC-5, godsf...@gmail.com 
>> wrote:
>>>
>>> Can you post a photo of how you have them wired please?
>>>
>>> On Wednesday, December 4, 2013 8:51:26 AM UTC-5, Doug Edey wrote:

 I've got 3 DS18B20 sensors on my bus at the moment, providing you've 
 got the sensors running in non-parasitic mode, I think you'll be fine.

 On Tuesday, December 3, 2013 8:13:31 PM UTC-5, lorena...@gmail.com 
 wrote:
>
> Thinking of replacing the dedicated microcontroller that runs my house 
> with a BBB. Being able to read the existing 1-Wire network will be 
> critical. Currently have 12 18B20 sensors on one bus, need more. Can the 
> kernel module described here actually address and read multiple sensors 
> on 
> the same bus? Can it search and retrieve addresses from unknown sensors? 
>
> I see people selling 8-port capes, as if maybe this is a simple one 
> device per bus routine...  Wouldn't help me! 
>
> As for the "considerations" of long buses, yes there was a learning 
> curve. I have both active pull-up and active pull-down, with careful 
> source-end termination. All cable is CAT-5, and all sensors are within 1m 
> of a single linear topology installation. In several cases the bus goes 
> out 
> one pair of the CAT-5 to a distant sensor and comes back on another pair 
> of 
> the same cable to continue to the next destination. Branching.in a star 
> fashion is death to 1-Wire. My current system works, reliably controlling 
> serious solar hot water and outdoor wood boiler operation that could blow 
> off expensive antifreeze fluid (a huge hassle to recharge) if anything 
> overheated. 
>
> Great long-bus reference:
> http://www.1wire.org/Files/Articles/1-Wire-Design%20Guide%20v1.0.pdf
>
 -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because 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/6a937fdb-7316-48b0-8b84-543757958c8c%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...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CALHSORoZHnv1PArG9zyCfV36esCb8T_%2BtJ-1zy7amx8TMOQocA%40mail.gmail.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
For more options, visit http:

Re: [beagleboard] Re: Dallas 1-Wire BeagleBone Black

2016-10-27 Thread Jason Kridner 


> On Oct 26, 2016, at 3:20 PM, William Hermans  wrote:
> 
> HI Mark,
> 
> So here: http://elinux.org/EBC_Exercise_31_Dallas_1-Wire#Reading_the_DS12B20
> 
> Shouldn't
> 
>> The t=24437 is the temperature in C times 1000. Warm up the probe and see 
>> what happens to the temp. 
>> 

I believe this is stated properly, but could be confusing. 

> Be: 
>> The t=24437 is the temperature in C times .001. Warm up the probe and see 
>> what happens to the temp. 
> 
> ?

Perhaps you mean:
Given t=24437, you can determine the temperature in C by multiplying t by .001. 
Warm up the probe and see what happens to the temp.

You could also say by dividing by 1000. Mark's language was right because he 
was describing how t is derived from the temperature and not the other way 
around. 

> 
> I do like your courses though. Really easy for someone like me , who has yet 
> had experience with one-wire devices.
> 
>> On Wed, Oct 26, 2016 at 7:23 AM, Mark A. Yoder  
>> wrote:
>> I've just posted[1] updated instructions on how to use Dallas 1-wire devices 
>> on the Bone.  I'm running:
>> bone$ uname -a
>> Linux yoder-debian-bone 4.4.21-ti-r47 #1 SMP Fri Sep 23 22:23:02 UTC 2016 
>> armv7l GNU/Linux
>> bone$ cat /ID.txt 
>> BeagleBoard.org Debian Image 2016-08-28
>> 
>> The instructions show how to deconfigure  P9_12 so the 1-wire driver can run 
>> on it.
>> 
>> --Mark
>> 
>> [1] http://elinux.org/EBC_Exercise_31_Dallas_1-Wire
>> 
>>> On Sunday, January 19, 2014 at 8:42:49 PM UTC-5, godsf...@gmail.com wrote:
>>> Can you post a photo of how you have them wired please?
>>> 
 On Wednesday, December 4, 2013 8:51:26 AM UTC-5, Doug Edey wrote:
 I've got 3 DS18B20 sensors on my bus at the moment, providing you've got 
 the sensors running in non-parasitic mode, I think you'll be fine.
 
> On Tuesday, December 3, 2013 8:13:31 PM UTC-5, lorena...@gmail.com wrote:
> Thinking of replacing the dedicated microcontroller that runs my house 
> with a BBB. Being able to read the existing 1-Wire network will be 
> critical. Currently have 12 18B20 sensors on one bus, need more. Can the 
> kernel module described here actually address and read multiple sensors 
> on the same bus? Can it search and retrieve addresses from unknown 
> sensors? 
> 
> I see people selling 8-port capes, as if maybe this is a simple one 
> device per bus routine...  Wouldn't help me! 
> 
> As for the "considerations" of long buses, yes there was a learning 
> curve. I have both active pull-up and active pull-down, with careful 
> source-end termination. All cable is CAT-5, and all sensors are within 1m 
> of a single linear topology installation. In several cases the bus goes 
> out one pair of the CAT-5 to a distant sensor and comes back on another 
> pair of the same cable to continue to the next destination. Branching.in 
> a star fashion is death to 1-Wire. My current system works, reliably 
> controlling serious solar hot water and outdoor wood boiler operation 
> that could blow off expensive antifreeze fluid (a huge hassle to 
> recharge) if anything overheated. 
> 
> Great long-bus reference:
> http://www.1wire.org/Files/Articles/1-Wire-Design%20Guide%20v1.0.pdf
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because 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/6a937fdb-7316-48b0-8b84-543757958c8c%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/CALHSORoZHnv1PArG9zyCfV36esCb8T_%2BtJ-1zy7amx8TMOQocA%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/FC414112-5988-431D-9027-10E88088AE2F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Green and PRU "Programmable Real-Time Unit" Interface to ADC using RemoteProc and RPMsg

2016-10-27 Thread Greg 
Hi William, yes those files are kind of mysterious.  Some are related to 
the C compiler/linker, and the others are related to remoteproc.  I used 
the examples from the PRU Support Package as a template.  The Makefile 
(which is really simple) has to be aware of these files.

It was pretty much plug-and-chug, as I followed the example patterns and 
there were no issues.  It would be good to understand them better, 
especially later if I start tweaking the kernel modules or creating new 
ones.

I'm probably need to ask the folks at TI for some comments on the functions 
of these files, and then write it up in an expanded Remoteproc chapter.

Regards,
Greg


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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/18dc22db-50bb-4a66-af58-4e831659c141%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Green + LCD (BB-BONE-LCD7-01-00A3) + CAN cape (TT3201 - 001 - 05)

2016-10-27 Thread Robert Nelson 
On Thu, Oct 27, 2016 at 8:03 AM, Aparna Velampudi
 wrote:
> I'm using a Beaglebone Green and trying to interface with both an LCD7
> (4DCAPE-70T) which is based off of the BB-BONE-LCD7-01:00A3 revision and the
> CAN Cape (TT3201-001:05 revision).
>
> The LCD cape comes with an expansion header (all the pins that aren't used
> by the LCD cape are ported to the header -- look at the data sheet linked
> above to get the idea). Both capes work perfectly individually, but when I
> try to use  them together, I get the following output.
>
>
> root@beaglebone:~# dmesg | grep cape
> [0.00] Kernel command line: console=ttyO0,115200n8
> root=UUID=5df5404c-a947-481b-8730-2a4bb771d33e ro rootfstype=ext4 rootwait
> coherent_pool=1M quiet cape_universal=enable
> [3.925280] bone_capemgr bone_capemgr: Baseboard:
> 'A335BNLT,BBG1,BBG116044309'
> [3.925315] bone_capemgr bone_capemgr:
> compatible-baseboard=ti,beaglebone-black - #slots=4
> [3.967132] bone_capemgr bone_capemgr: slot #0: '4D 7.0 LCD CAPE-
> 4DCAPE-70T ,00A3,4D SYSTEMS  ,BB-BONE-LCD7-01'
> [4.023037] bone_capemgr bone_capemgr: slot #1: No cape found
> [4.082948] bone_capemgr bone_capemgr: slot #2: No cape found
> [4.112954] bone_capemgr bone_capemgr: slot #3: 'TT3201 CAN Bus
> Cape,05,TowerTech,TT3201-001'
> [4.113486] bone_capemgr bone_capemgr: initialized OK.
> [4.130310] bone_capemgr bone_capemgr: slot #3: TT3201-001 conflict P9.27
> (#0:BB-BONE-LCD7-01)
> [4.139161] bone_capemgr bone_capemgr: slot #3: Failed verification
> [4.154974] bone_capemgr bone_capemgr: slot #3: TT3201-001 conflict P9.27
> (#0:BB-BONE-LCD7-01)
> [4.165624] bone_capemgr bone_capemgr: slot #0: dtbo
> 'BB-BONE-LCD7-01-00A3.dtbo' loaded; overlay id #0
> [4.170778] bone_capemgr bone_capemgr: slot #3: Failed verification
> [4.183178] bone_capemgr bone_capemgr: loader: failed to load slot-3
> TT3201-001:05 (prio 0)
> [   14.366425] bone_capemgr bone_capemgr: part_number 'GPIO-Test', version
> 'N/A'
> [   14.366464] bone_capemgr bone_capemgr: slot #4: override
> [   14.366482] bone_capemgr bone_capemgr: Using override eeprom data at slot
> 4
> [   14.366499] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,GPIO-Test'
>
>
> I'm using Debian with  the following kernel:
>
> root@beaglebone:~# uname -r
> 4.1.15-ti-rt-r43
>
>
> I've tried doing the obvious thing by taking the conflict pin  (P9_27)
> entirely out of the LCD .dts file by changing it to P9_11 (which isn't used
> by either) (then compiled and put  the .dtbo in /lib/firmware) but that
> doesn't work. This is the .dts file for BB-BONE-LCD7-01-00A3

after you "copy" it to /lib/firmware/

run:

sudo update-initramfs -uk `uname -r`

and reboot...

to update the version of the *.dtbo stored in the initramfs..

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

Re: [beagleboard] Beaglebone Green and PRU "Programmable Real-Time Unit" Interface to ADC using RemoteProc and RPMsg

2016-10-27 Thread Greg 
Hi Jason, yes I will look into it.  My next priority is creating a higher 
quality youtube video using open-source video capture tools.
I'm going to get that done this weekend, and I will also look into the 
websites you have suggested.

Regards,
Greg

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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/0d26bad4-6d13-47ac-b16e-a1800813c88e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Understanding and reducing boot time

2016-10-27 Thread Jean-Sebastien Stoezel 
Lazarman:

To answer your question, yes I have used the Google search in the group and 
I did not find something that applied directly to my questions:
- The information I found on how to disable the timeout where either to 
vague for me to figure out, or did not seem to apply to the configuration 
on my board,
- I did not find anything related to customizing the bootup, apart from 
enabling/disabling capes manually in uEnv.txt. My question is related to 
forcing states in the bootup scripts rather than automatic detection

Now since you seem to have written a tutorial on how to speed up boot time, 
and since this did not show up in the search results, would it be possible 
for you to link directly to it? This I feel, would be a useful piece of 
information to this thread.

Regards,
JS


On Tuesday, October 25, 2016 at 11:40:50 AM UTC-5, Jean-Sebastien Stoezel 
wrote:
>
> Hi:
>
> I am running a Beagle Bone with a custom cape and I am looking for ways to 
> reduce its boot time. The cape will always be the same and so I'd like to 
> see what it is I can change to reduce or completely remove custom auto 
> detection scripts.
> As of now, the board boots in 18s, 8s are spent in the kernel, 10s are 
> spent in user space.
>
> I have seen numbers out stating that the kernel can boot in less than 2s. 
> I'd be interested to know how this is possible. I am aware of a timeout 
> being used in the kernel, though I am not sure how to disable this (using 
> 4.1.33-bone-rt-r24).
>
> Currently generic-board-startup.service seems to be the service that takes 
> the longest to complete. Looking at what it does, it seems to be invoking 
> am335x_evm.h.sh. I am wondering if I could disable anything related to 
> detecting capes (including trying to read the eeprom). At this time I can 
> see lines 30 to 55 in the scripts being related to eeprom flashing/reading, 
> though I am not sure this is targetting the cape's eeprom.
>
> In general, how would I go about disabling auto detection of capes? Would 
> I need to edit these scripts? Or is there a cleaner way to disable features 
> by editing a config file?
>
> Regards,
> JS
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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/a8ddaef0-61e9-461a-9f69-a02f9b3a0e82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone Green + LCD (BB-BONE-LCD7-01-00A3) + CAN cape (TT3201 - 001 - 05)

2016-10-27 Thread Aparna Velampudi 
I'm using a Beaglebone Green and trying to interface with both an LCD7 
(4DCAPE-70T) 
 
which 
is based off of the BB-BONE-LCD7-01:00A3 revision and the CAN Cape (
TT3201-001:05 
 
revision).

The LCD cape comes with an expansion header (all the pins that aren't used 
by the LCD cape are ported to the header -- look at the data sheet linked 
above to get the idea). Both capes work perfectly individually, but when I 
try to use  them together, I get the following output.


root@beaglebone:~# dmesg | grep cape
[0.00] Kernel command line: console=ttyO0,115200n8 
root=UUID=5df5404c-a947-481b-8730-2a4bb771d33e ro rootfstype=ext4 rootwait 
coherent_pool=1M quiet cape_universal=enable
[3.925280] bone_capemgr bone_capemgr: Baseboard: 
'A335BNLT,BBG1,BBG116044309'
[3.925315] bone_capemgr bone_capemgr: 
compatible-baseboard=ti,beaglebone-black - #slots=4
[3.967132] bone_capemgr bone_capemgr: slot #0: '4D 7.0 LCD CAPE- 
4DCAPE-70T ,00A3,4D SYSTEMS  ,BB-BONE-LCD7-01'
[4.023037] bone_capemgr bone_capemgr: slot #1: No cape found
[4.082948] bone_capemgr bone_capemgr: slot #2: No cape found
[4.112954] bone_capemgr bone_capemgr: slot #3: 'TT3201 CAN Bus 
Cape,05,TowerTech,TT3201-001'
[4.113486] bone_capemgr bone_capemgr: initialized OK.
[4.130310] bone_capemgr bone_capemgr: slot #3: TT3201-001 conflict 
P9.27 (#0:BB-BONE-LCD7-01)
[4.139161] bone_capemgr bone_capemgr: slot #3: Failed verification
[4.154974] bone_capemgr bone_capemgr: slot #3: TT3201-001 conflict 
P9.27 (#0:BB-BONE-LCD7-01)
[4.165624] bone_capemgr bone_capemgr: slot #0: dtbo 
'BB-BONE-LCD7-01-00A3.dtbo' loaded; overlay id #0
[4.170778] bone_capemgr bone_capemgr: slot #3: Failed verification
[4.183178] bone_capemgr bone_capemgr: loader: failed to load slot-3 
TT3201-001:05 (prio 0)
[   14.366425] bone_capemgr bone_capemgr: part_number 'GPIO-Test', version 
'N/A'
[   14.366464] bone_capemgr bone_capemgr: slot #4: override
[   14.366482] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 4
[   14.366499] bone_capemgr bone_capemgr: slot #4: 'Override Board 
Name,00A0,Override Manuf,GPIO-Test'


I'm using Debian with  the following kernel:

root@beaglebone:~# uname -r
4.1.15-ti-rt-r43


I've tried doing the obvious thing by taking the conflict pin  (P9_27) 
entirely out of the LCD .dts file by changing it to P9_11 (which isn't used 
by either) (then compiled and put  the .dtbo in /lib/firmware) but that 
doesn't work. This is the .dts file for BB-BONE-LCD7-01-00A3

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

#include 
#include 
#include 

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green";

/* identification */
part-number = "BB-BONE-LCD7-01";
version = "00A3";

/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P8.45", /* lcd: lcd_data0 */
"P8.46", /* lcd: lcd_data1 */
"P8.43", /* lcd: lcd_data2 */
"P8.44", /* lcd: lcd_data3 */
"P8.41", /* lcd: lcd_data4 */
"P8.42", /* lcd: lcd_data5 */
"P8.39", /* lcd: lcd_data6 */
"P8.40", /* lcd: lcd_data7 */
"P8.37", /* lcd: lcd_data8 */
"P8.38", /* lcd: lcd_data9 */
"P8.36", /* lcd: lcd_data10 */
"P8.34", /* lcd: lcd_data11 */
"P8.35", /* lcd: lcd_data12 */
"P8.33", /* lcd: lcd_data13 */
"P8.31", /* lcd: lcd_data14 */
"P8.32", /* lcd: lcd_data15 */
"P8.27", /* lcd: lcd_vsync */
"P8.29", /* lcd: lcd_hsync */
"P8.28", /* lcd: lcd_pclk */
"P8.30", /* lcd: lcd_ac_bias_en */
"P9.11", /* lcd: gpio3_19 DISPEN */
"P9.12", /* led: gpio1_28 LED */
"P9.14", /* pwm: ehrpwm1a PWM_BL */
"P9.15", /* keys: gpio1_16 LEFT */
"P9.23", /* keys: gpio1_17 RIGHT */
"P9.16", /* keys: gpio1_19 UP */
"P9.30", /* keys: gpio3_16 DOWN */
"P9.21", /* keys: gpio0_3 ENTER */

"ehrpwm1a",
"gpio0_30", /* DISPEN */
"gpio1_28", /* LED */
"gpio1_16", /* LEFT */
"gpio1_17", /* RIGHT */
"gpio1_19", /* UP */
"gpio3_16", /* DOWN */
"gpio0_3", /* ENTER */
"lcdc",
"tscadc";

fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {

bb_lcd_led_pins: pinmux_bb_lcd_led_pins {
pinctrl-single,pins = <
BONE_P9_12 (PIN_INPUT | MUX_MODE7) /* gpmc_ben1.gpio1_28, INPUT | PULLDIS | 
MODE7 */
>;
};

bb_lcd_pwm_backlight_pins: pinmux_bb_lcd_pwm_backlight_pins {
pinctrl-single,pins = <
BONE_P9_14 (PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* gpmc_a2.ehrpwm1a */
>;
};

bb_lcd_lcd_pins: pinmux_bb_lcd_lcd_pins {
pinctrl-single,pins = <
BONE_P9_11 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* mcasp0_fsr.gpio3_19 */

BONE_P8_45 (PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0 */
BONE_P8_46 (PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1 */
BONE_P8_43 (PIN_OUTPUT | MUX_MODE0) /* lcd