[beagleboard] Re: Signed BBB drivers for Windows 10

[Nathan Holder]

I disabled driver signature requirement and the driver install worked after 
that.
Search for "disable signature requirement for drivers windows 10".
If I remember correctly you restart while holding shift, (press shift then 
click on restart). Then after restart navigate to screen with 10-15 
options, choose disable signature requirement for drivers.

On Thursday, October 1, 2015 at 5:50:13 PM UTC-4, msh wrote:
>
> Hi Everyone,
>
> Where can I find signed drivers for Windows 10?
>
> Thanks 
>
> Manish
>

-- 
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/dd420c51-c0e8-4a73-b9af-e45aad9c56d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Same Ole Game, Different Take/Seth

[Mala Dies]

Hello,

I am using a couple different books. I am using the Programming the 
BeagleBone Black from Monk and another book called Evil Genius by Rush. It 
is a similar book on the BBB. I had some odd connections at first. You are 
right. I guess I am learning what I am doing.

Seth

P.S. I lost track of all the info. I have accumulated over the last year. I 
will try to keep better records. If you have any questions, let me know. I 
will look up some items on what I am discussing. I got the readings from 
the BBGW to list Celsius and Fahrenheit near what the house is listing on 
the dial. I am still about 10 degrees off, though.  

On Tuesday, July 11, 2017 at 9:53:07 PM UTC-5, Dennis Lee Bieber wrote:
>
> On Tue, 11 Jul 2017 17:23:17 -0700 (PDT), Mala Dies 
>  declaimed the following: 
>
> >Hello Again Mr. Dennis, 
> > 
> >Seth here. I have done some small time work on what wiring I have 
> >concocted. Here goes: 
> > 
> >TMP36: 
> > 
> >Pin 1 is + Vs and it is connected to P9_34 or GNDA_ADC. 
> > 
> >Pin 2 is Vout and it is connected to P9_40 or AIN1. 
> > 
> >and... 
> > 
> >Pin 3 is GND and it is connected to P9_03 or VDD_3V3. 
> > 
> >Now...I have been wrong before and I am just listening to the info. from 
> >the book. I will do some extra research on this project from the 
>
> Which book? 
>
> [Monk] 
> With the TMP36 oriented |) the top pin is connected to 
> 3.3V, the 
> middle pin is connected to the ADC input, and the bottom pin is connected 
> to ADC GND. 
>
> [Chavan] 
> With the TMP36 oriented (|, the top pin is connected to 
> ADC GND, 
> the middle pin is connected to the ADC input, and the bottom pin is 
> connected to 3.3V 
>
> Doesn't matter what beagle you use... When looking at the flat 
> side of 
> the TMP36, the middle pin goes to the ADC input, the left pin goes to the 
> +V and the right pin goes to the GND. While different beagles may put 
> those 
> items on different sockets, the general description is the same -- GND is 
> ground [0V], +V is positive voltage (the TMP36 can be powered from around 
> 3 
> to 6 volts, as I recall [didn't save the spec sheet]), and the desired 
> signal is the middle. 
> -- 
> Wulfraed Dennis Lee Bieber AF6VN 
> wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.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/b8365ff3-1c34-48a2-95b0-eb9d4bcf1e4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: spi / shiftout.js in 2017-03-19 image

[William Hermans]

On Tue, Jul 11, 2017 at 8:17 PM, William Hermans  wrote:

> SPI is notoriously finicky when it comes to high speed, and noise. Since
> I'm not an EE, I could not say much more than that. Typically though, from
> what I understand, traces can not be very long.
>

Additionally, this could very well be a Nodejs bottleneck. I've personally
experienced first hand how slow Nodejs really is when working with fast
moving code. I notice the title "shiftout.js" but you're also talking about
C too. So maybe you're using a hybrid of the two ? A bit confusing, but
maybe some clarity on the subject is deserved ?

Using my own  javascript library, which pretty much just encapsulates the
sysfs file entries. When toggling GPIO, I've noticed it peters off at about
1Khz, or slightly less. That's just using a simple XOR binary operation.
Arguably, using /dev/mem/ and mmap() would be faster, but the speed of
scripting language code is alway going ot be a bottle neck. First, because
it's an interpreted language, and second, because the "binary" size is huge
compared to something like C. It's going ot be a lot slower.

-- 
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/CALHSORo6F7B9jmKH0rvJYgyK1%3DRs6jsZ_YPxMyxK526%2B7XWoZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: spi / shiftout.js in 2017-03-19 image

[William Hermans]

SPI is notoriously finicky when it comes to high speed, and noise. Since
I'm not an EE, I could not say much more than that. Typically though, from
what I understand, traces can not be very long.

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

Re: [beagleboard] Re: Windows 10 Bone_D64.exe Failing

[William Hermans]

Well, this is like a 2 year old post . . . Let me just say this. I'm
running Windows 10 pro on a Lenovo Thinkpad, and I happened to have a BBG
plugged into a USB 3.0 port off this laptop for power( using ethernet for
networking ), and Windows update automatically installed the NDIS driver
for it the update after . . . So, I have not used it, but no problems with
it installing at all. Also, I did not run the Bone_D64 installer either . .
.

On Tue, Jul 11, 2017 at 6:52 PM, Nathan Holder 
wrote:

> I had the same issue, I disabled signature requirement for drivers.
>
> On Wednesday, August 12, 2015 at 11:13:13 PM UTC-4, mscleavite wrote:
>>
>> I have just upgraded to Windows 10 on a machine that I have not
>> previously connected my BBB to.  I had success on other windows 8 machines
>> as well as SSHing using Putty.  I have spent SOME time searching forums and
>> not finding much at all on Windows 10.  During the install of the
>> Bone_D64.exe, the driver the status returned on all the drivers is "Install
>> Failed".  Let the flaming begin.  Or hopefully there is someone out
>> there that has encountered and concurred this.
>>
> --
> 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/a77d0884-5748-4362-aa94-368ee4381609%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/CALHSORo9MO8f2DwNzPPaTi%3D3%3DUbrbG%2B3VGj%3D2oSjHXRxfHMcrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: spi / shiftout.js in 2017-03-19 image

[Jeff Albrecht]

On Friday, July 7, 2017 at 1:53:10 PM UTC-7, Jeff Albrecht wrote:

[...]
> Are there any other changes that I may have missed? Suggestions?
>

Regarding the SPI test in Exploring BeagleBone Black. Got it, works on my 
machine now! Thank you William and Gaurav for your input. It turned out 
that the default clock speed in the spi595.c code was to fast for the 
74HC595N I am using. I changed it down from 1mhz to 10khz. I powered it 
from 3.3vdc. If I'm reading the data sheet correctly it looks like it 
should be able to do 4mhz at 2vdc. Perhaps this chip was a reject or 
counterfeit? Perhaps the setup on a solder-less breadboard had some 
negative effect. Or???






   // transfer.speed_hz = 100;//the speed in Hz
   transfer.speed_hz = 1;//the speed in Hz



# in lieu of loading a device overlay I used config-pin to configure SPI. - 
Thanks Drew pdp7

$ cat /etc/dogtag
$ BeagleBoard.org Debian Image 2017-03-19
$ uname -a
$ Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l 
GNU/Linux

$ config-pin -l P9.17 #SPI0_CS
$ config-pin -l P9.18 #SPI0_D1
$ config-pin -l P9.22 #SPI0_SCLK
$ config-pin -l P9.21 #SPI0_D0

$ ./spi595


Along the way I learned how to use the SPI decoders on my Saleae logic 8 
and Rigol DS1054z








-- 
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/abadd68f-63b4-4c59-aff0-31808c257478%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Windows 10 Bone_D64.exe Failing

[Nathan Holder]

I had the same issue, I disabled signature requirement for drivers.

On Wednesday, August 12, 2015 at 11:13:13 PM UTC-4, mscleavite wrote:
>
> I have just upgraded to Windows 10 on a machine that I have not previously 
> connected my BBB to.  I had success on other windows 8 machines as well as 
> SSHing using Putty.  I have spent SOME time searching forums and not 
> finding much at all on Windows 10.  During the install of the Bone_D64.exe, 
> the driver the status returned on all the drivers is "Install Failed".  Let 
> the flaming begin.  Or hopefully there is someone out there that has 
> encountered and concurred this. 
>

-- 
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/a77d0884-5748-4362-aa94-368ee4381609%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Same Ole Game, Different Take/Seth

[Mala Dies]

Hello Sir,

Supposedly, the GNDA_ADC pin on the BBGW makes less noise. This noise would 
create a higher fluctuation of distance from the actual temp. in the 
environment. 

Seth

P.S. Now, the GND to VDD_3V3 had some idea behind it but was not listed in 
the book. I had to put value at 63 degrees Celsius but it was still off by 
about two degrees with the old software and old hook-up. Now, the temp. is 
still off by about 10 degrees in Fahrenheit with the correct hook-up and 
current software.

On Tuesday, July 11, 2017 at 7:40:51 PM UTC-5, RobertCNelson wrote:
>
> On Tue, Jul 11, 2017 at 7:23 PM, Mala Dies  
> wrote: 
> > Hello Again Mr. Dennis, 
> > 
> > Seth here. I have done some small time work on what wiring I have 
> concocted. 
> > Here goes: 
> > 
> > TMP36: 
> > 
> > Pin 1 is + Vs and it is connected to P9_34 or GNDA_ADC. 
> > 
> > Pin 2 is Vout and it is connected to P9_40 or AIN1. 
> > 
> > and... 
> > 
> > Pin 3 is GND and it is connected to P9_03 or VDD_3V3. 
>
> Why are you connecting +Vs to GND, and GND to Vdd? 
>
> 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/07072276-0282-43f4-9da4-97485b673b15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Same Ole Game, Different Take/Seth

[Mala Dies]

Hello,

So,

TMP36:

+ Vs is now at VDD_3V3

GND is now at DGND

I did configure the old software to work but this is easier. 

Seth 


On Tuesday, July 11, 2017 at 7:40:51 PM UTC-5, RobertCNelson wrote:
>
> On Tue, Jul 11, 2017 at 7:23 PM, Mala Dies  
> wrote: 
> > Hello Again Mr. Dennis, 
> > 
> > Seth here. I have done some small time work on what wiring I have 
> concocted. 
> > Here goes: 
> > 
> > TMP36: 
> > 
> > Pin 1 is + Vs and it is connected to P9_34 or GNDA_ADC. 
> > 
> > Pin 2 is Vout and it is connected to P9_40 or AIN1. 
> > 
> > and... 
> > 
> > Pin 3 is GND and it is connected to P9_03 or VDD_3V3. 
>
> Why are you connecting +Vs to GND, and GND to Vdd? 
>
> 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/d3e1d74d-7823-433a-924a-5e4a28cb0b1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Same Ole Game, Different Take/Seth

[Mala Dies]

Hello,

The instructions on the book said to connect the pins of the TMP36 via 
jumper wires to the BBB/BBGW in that manner. I am using a BBGW instead of 
the BBB or BBBW for this project.

Seth

P.S. Should I have the jumper wires connecting to different pins on the 
BBGW?

On Tuesday, July 11, 2017 at 7:40:51 PM UTC-5, RobertCNelson wrote:
>
> On Tue, Jul 11, 2017 at 7:23 PM, Mala Dies  
> wrote: 
> > Hello Again Mr. Dennis, 
> > 
> > Seth here. I have done some small time work on what wiring I have 
> concocted. 
> > Here goes: 
> > 
> > TMP36: 
> > 
> > Pin 1 is + Vs and it is connected to P9_34 or GNDA_ADC. 
> > 
> > Pin 2 is Vout and it is connected to P9_40 or AIN1. 
> > 
> > and... 
> > 
> > Pin 3 is GND and it is connected to P9_03 or VDD_3V3. 
>
> Why are you connecting +Vs to GND, and GND to Vdd? 
>
> 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/371931cd-90a5-42a2-9c18-e71eeb8cbe97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Same Ole Game, Different Take/Seth

[Mala Dies]

Hello Again,

I read the schematic on the book. The book states via photo to wire things 
up this way.

Seth

On Tuesday, July 11, 2017 at 8:03:05 PM UTC-5, Mala Dies wrote:
>
> Hello,
>
> The instructions on the book said to connect the pins of the TMP36 via 
> jumper wires to the BBB/BBGW in that manner. I am using a BBGW instead of 
> the BBB or BBBW for this project.
>
> Seth
>
> P.S. Should I have the jumper wires connecting to different pins on the 
> BBGW?
>
> On Tuesday, July 11, 2017 at 7:40:51 PM UTC-5, RobertCNelson wrote:
>>
>> On Tue, Jul 11, 2017 at 7:23 PM, Mala Dies  wrote: 
>> > Hello Again Mr. Dennis, 
>> > 
>> > Seth here. I have done some small time work on what wiring I have 
>> concocted. 
>> > Here goes: 
>> > 
>> > TMP36: 
>> > 
>> > Pin 1 is + Vs and it is connected to P9_34 or GNDA_ADC. 
>> > 
>> > Pin 2 is Vout and it is connected to P9_40 or AIN1. 
>> > 
>> > and... 
>> > 
>> > Pin 3 is GND and it is connected to P9_03 or VDD_3V3. 
>>
>> Why are you connecting +Vs to GND, and GND to Vdd? 
>>
>> 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/f8d8e585-7878-4891-8b46-0442ff0076b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Same Ole Game, Different Take/Seth

[Robert Nelson]

On Tue, Jul 11, 2017 at 7:23 PM, Mala Dies  wrote:
> Hello Again Mr. Dennis,
>
> Seth here. I have done some small time work on what wiring I have concocted.
> Here goes:
>
> TMP36:
>
> Pin 1 is + Vs and it is connected to P9_34 or GNDA_ADC.
>
> Pin 2 is Vout and it is connected to P9_40 or AIN1.
>
> and...
>
> Pin 3 is GND and it is connected to P9_03 or VDD_3V3.

Why are you connecting +Vs to GND, and GND to Vdd?

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

[beagleboard] Re: Same Ole Game, Different Take/Seth

[Mala Dies]

Hello Again Mr. Dennis,

Seth here. I have done some small time work on what wiring I have 
concocted. Here goes:

TMP36:

Pin 1 is + Vs and it is connected to P9_34 or GNDA_ADC.

Pin 2 is Vout and it is connected to P9_40 or AIN1.

and...

Pin 3 is GND and it is connected to P9_03 or VDD_3V3.

Now...I have been wrong before and I am just listening to the info. from 
the book. I will do some extra research on this project from the 
schematic: 
http://www.analog.com/media/en/technical-documentation/data-sheets/TMP35_36_37.pdf.
 
I got this link from Digi Key. They still sell these TMP36 sensors. 

Seth

P.S. If you get bored, let me know what you think. Oh and I just changed 
the uEnv.txt file in the /boot directory to 
enable=BB-AIN1,BB-GNDA_ADC,VDD_3V3 and then I rebooted the machine. I am 
getting an exact read of the 130 C degrees and 201 F degrees. I think this 
will better suit your needs if you are choosing to still help me out. Thank 
you again, sir. 






On Tuesday, July 11, 2017 at 6:58:24 PM UTC-5, Mala Dies wrote:
>
> Hello Dennis,
>
> Yep...I changed the wiring and changed a uEnv.txt file in the /boot 
> directory. I have the P9_40/AIN1 pin connect now instead of the P9_39/AIN0. 
> When I stated that I changed a file, I changed the file to enable 
> BB-ADC1,BB-ADC2 instead of having it enabled at BB-AIN0, BB-AIN1. 
>
> The software is completely different too. I used this set of software to 
> check the TMP36 just like the older software I used in a post not too long 
> ago.
>
> Seth
>
> P.S. I will work backwards like you are discussing and I will keep trying. 
> I know I should have some pins enabled with my Cape Universal disabled. I 
> am probably way off base but this is what I have done so far. Sorry for not 
> giving every detail. I will wait to hear from you again while attempt to 
> work some magic. 
>
> On Monday, July 10, 2017 at 9:27:41 PM UTC-5, Dennis Lee Bieber wrote:
>>
>> On Mon, 10 Jul 2017 16:10:50 -0700 (PDT), Mala Dies 
>>  declaimed the following: 
>>
>> > 
>> >I have another set of software that I picked up along the way, i.e. 
>> >probably from that book, "Evil Genuis," series from Mr. Rush. Anyway, 
>> here 
>> >goes it. Oh but first, I know people are getting tired of seeing the 
>> same 
>> >ole, same ole. This does not discourage me from posting. 
>> > 
>>
>> What is discouraging is the lack of any attempts to analyze/debug 
>> the 
>> problem... Posting code samples from books, stating an invalid result, 
>> and 
>> that is where the effort seems to end. 
>>
>> >*var b = require('bonescript');* 
>> > 
>> >*var inputPin = "P9_40";* 
>> > 
>> >*getBeagleTemp();* 
>> > 
>> >*function getBeagleTemp() {* 
>> >*var value = b.analogRead("P9_40");* 
>> > 
>> >*var millivolts = value * 1800;* 
>> >*var x = (millivolts - 500)/10;* 
>> >*var z = (x * 9/5) - 32;* 
>> >*setTimeout(getBeagleTemp, 1);* 
>> > 
>> >*console.log("x=" + x + "\tz=" + z);* 
>> >*}* 
>> > 
>>
>> >I am getting temperatures in the Fahrenheit of 201 and in Celsius of 
>> 129. 
>> >This is not my temp. in the house. 
>> > 
>>
>> Again, work the results backwards to figure out the numbers 
>> (again, 
>> ignore Fahrenheit). 
>>
>> x = 129 
>>
>> 129 = (mV - 500) / 10 
>> 1290 = mV - 500 
>> 1790 = mV 
>>
>> {Not important, since it just converts the voltage back to the analogRead 
>> 0..1 range 
>> mV = val * 1800 
>> 1790 = val * 1800 
>> 1790/1800 = val 
>> 0.9944 = val 
>> } 
>>
>> Before, the reported temperature was near -50, now it is near 
>> +130. 
>>
>> -50 is GND (0.0V), +130 is maximum (safe) for BB (1.8V). The 
>> minor 
>> differences could be capacitive coupling and cross-talk on the wiring. 
>>
>> My only logical conclusion is that you have changed the wiring 
>> some, 
>> and are not properly connected to the TMP36, instead somehow being 
>> connected to either the GND or the ADC-Voltage source. 
>> -- 
>> Wulfraed Dennis Lee Bieber AF6VN 
>> wlf...@ix.netcom.comHTTP://wlfraed.home.netcom.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/9eaae0a7-2c6b-4cb3-9863-d10d2ebfa65e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Same Ole Game, Different Take/Seth

[Mala Dies]

Hello Dennis,

Yep...I changed the wiring and changed a uEnv.txt file in the /boot 
directory. I have the P9_40/AIN1 pin connect now instead of the P9_39/AIN0. 
When I stated that I changed a file, I changed the file to enable 
BB-ADC1,BB-ADC2 instead of having it enabled at BB-AIN0, BB-AIN1. 

The software is completely different too. I used this set of software to 
check the TMP36 just like the older software I used in a post not too long 
ago.

Seth

P.S. I will work backwards like you are discussing and I will keep trying. 
I know I should have some pins enabled with my Cape Universal disabled. I 
am probably way off base but this is what I have done so far. Sorry for not 
giving every detail. I will wait to hear from you again while attempt to 
work some magic. 

On Monday, July 10, 2017 at 9:27:41 PM UTC-5, Dennis Lee Bieber wrote:
>
> On Mon, 10 Jul 2017 16:10:50 -0700 (PDT), Mala Dies 
>  declaimed the following: 
>
> > 
> >I have another set of software that I picked up along the way, i.e. 
> >probably from that book, "Evil Genuis," series from Mr. Rush. Anyway, 
> here 
> >goes it. Oh but first, I know people are getting tired of seeing the same 
> >ole, same ole. This does not discourage me from posting. 
> > 
>
> What is discouraging is the lack of any attempts to analyze/debug 
> the 
> problem... Posting code samples from books, stating an invalid result, and 
> that is where the effort seems to end. 
>
> >*var b = require('bonescript');* 
> > 
> >*var inputPin = "P9_40";* 
> > 
> >*getBeagleTemp();* 
> > 
> >*function getBeagleTemp() {* 
> >*var value = b.analogRead("P9_40");* 
> > 
> >*var millivolts = value * 1800;* 
> >*var x = (millivolts - 500)/10;* 
> >*var z = (x * 9/5) - 32;* 
> >*setTimeout(getBeagleTemp, 1);* 
> > 
> >*console.log("x=" + x + "\tz=" + z);* 
> >*}* 
> > 
>
> >I am getting temperatures in the Fahrenheit of 201 and in Celsius of 129. 
> >This is not my temp. in the house. 
> > 
>
> Again, work the results backwards to figure out the numbers 
> (again, 
> ignore Fahrenheit). 
>
> x = 129 
>
> 129 = (mV - 500) / 10 
> 1290 = mV - 500 
> 1790 = mV 
>
> {Not important, since it just converts the voltage back to the analogRead 
> 0..1 range 
> mV = val * 1800 
> 1790 = val * 1800 
> 1790/1800 = val 
> 0.9944 = val 
> } 
>
> Before, the reported temperature was near -50, now it is near 
> +130. 
>
> -50 is GND (0.0V), +130 is maximum (safe) for BB (1.8V). The minor 
> differences could be capacitive coupling and cross-talk on the wiring. 
>
> My only logical conclusion is that you have changed the wiring 
> some, 
> and are not properly connected to the TMP36, instead somehow being 
> connected to either the GND or the ADC-Voltage source. 
> -- 
> Wulfraed Dennis Lee Bieber AF6VN 
> wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.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/4b7db55b-2436-4fb2-ae1c-97209df12cc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] where is capemgr?

[Clark Briggs]

Robert,
Thanks.
I have spent a good bit of time with the robotics cape through working with 
James Strawson. He has constructed a very good set of aps and library for 
newbies to use.  Those are his main constituents, IMHO.
I have been using his board without his code base with his help. He and I 
differ on certain value judgements, like using mmap for I/O access. So...
If I'm not using his libraries and want to start capemgr and manually export 
and use BBB I/O and robotics cape I/O, how to do that?
I tried using systemctl to start capemgr.service but don't see any results but 
don't know where its gripes would get posted.
Clark

-Original Message-
From: Robert Nelson [mailto:robertcnel...@gmail.com] 
Sent: Tuesday, July 11, 2017 12:37 PM
To: Beagle Board 
Cc: Clark Briggs 
Subject: Re: [beagleboard] where is capemgr?

On Tue, Jul 11, 2017 at 2:28 PM,   wrote:
> After watching the great progress, I started in. I have the 3/19/2017 
> latest image with apt-get upgrades running on a Rev C BBB with a Rev C 
> Robotics Cape. All in all, the process worked well.  But I can't find 
> capemgr. I went looking for it because I want to access analog I/O and 
> other stuff. Recent emails from here-ish say capemgr is supposed to be 
> in /sys/devices/platform but not.  To get analog I/O, I put 
> "cape_enable=bone_capemgr.enable_partno=BB-ADC" in uEnv.txt, but no 
> /sys/bus/iio.
> some info
> debian@sim15:~$ uname -a
> Linux sim15 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l 
> GNU/Linux debian@sim15:~$ cat /etc/dogtag BeagleBoard.org Debian Image 
> 2017-03-19 debian@sim15:~$ systemctl status capemgr.service ● 
> capemgr.service - Cape Manager Service
>Loaded: loaded (/lib/systemd/system/capemgr.service; enabled; 
> vendor
> preset: enabled)
>Active: inactive (dead) since Tue 2017-07-11 18:46:54 UTC; 32min ago
>   Process: 4598 ExecStart=/bin/sh /opt/scripts/boot/capemgr.sh 
> (code=exited,
> status=0/SUCCESS)
>  Main PID: 4598 (code=exited, status=0/SUCCESS) Jul 11 18:46:53 sim15 
> systemd[1]: Starting Cape Manager Service...
> Jul 11 18:46:54 sim15 systemd[1]: Started Cape Manager Service.

The BB + Robotic Cape boots a special device tree binary, thus capemgr is 
disabled. the librobotic library expects this combination to have things setup 
a certain way, as it utilzes /dev/mem to access the gpio/adc/etc.

As I don't have that cape, and it's still not listed for sale, this isn't going 
to change anytime soon.

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/feb4a96ffe914b3e93c5e1e1d1328e0b%40Exchange1.ata-engineering.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] FrSky Receivers

[mike]

Has anyone had any luck connecting non DSM2 / DSMX up to the Beagle Bone 
Blue?

I have FrSky Taranis X9D Plus ACCST Radio and D4R-ii Receiver 
(http://www.getfpv.com/frsky-d4r-ii-4ch-2-4ghz-accst-receiver-w-telemetry.html) 
lying around.  

I was wondering if they would be compatible with the DMS2/DMX port on the 
board or another port on the board.  Since the board itself does not have a 
built in receiver (AFAIK) and both receivers output CPPM - I would think 
its more or less agnostic to the receiver.  

Lastly, if not supported, I would imagine it's not a far leap to support 
communicating with the D4R-ii (aka just software at that point).  

Thanks in advance.
Cheers.
... 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/4ba22a9f-224b-4a40-b794-a54bcab25f6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] where is capemgr?

[Robert Nelson]

On Tue, Jul 11, 2017 at 2:49 PM, Clark Briggs  wrote:
> Robert,
> Thanks.
> I have spent a good bit of time with the robotics cape through working with 
> James Strawson. He has constructed a very good set of aps and library for 
> newbies to use.  Those are his main constituents, IMHO.
> I have been using his board without his code base with his help. He and I 
> differ on certain value judgements, like using mmap for I/O access. So...

Yeah, i'd like to rip all those mmap calls out of the library, and
just access them thru kernel userspace. ;)

> If I'm not using his libraries and want to start capemgr and manually export 
> and use BBB I/O and robotics cape I/O, how to do that?
> I tried using systemctl to start capemgr.service but don't see any results 
> but don't know where its gripes would get posted.

It's not a service file, it's the device tree binary:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-roboticscape.dts#L19

Change:

#include "am335x-bone-common-no-capemgr.dtsi"

to:

#include "am335x-bone-common.dtsi"

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

Re: [beagleboard] where is capemgr?

[Robert Nelson]

On Tue, Jul 11, 2017 at 2:28 PM,   wrote:
> After watching the great progress, I started in. I have the 3/19/2017 latest
> image with apt-get upgrades running on a Rev C BBB with a Rev C Robotics
> Cape. All in all, the process worked well.  But I can't find capemgr. I went
> looking for it because I want to access analog I/O and other stuff. Recent
> emails from here-ish say capemgr is supposed to be in /sys/devices/platform
> but not.  To get analog I/O, I put
> "cape_enable=bone_capemgr.enable_partno=BB-ADC" in uEnv.txt, but no
> /sys/bus/iio.
> some info
> debian@sim15:~$ uname -a
> Linux sim15 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l
> GNU/Linux
> debian@sim15:~$ cat /etc/dogtag
> BeagleBoard.org Debian Image 2017-03-19
> debian@sim15:~$ systemctl status capemgr.service
> ● capemgr.service - Cape Manager Service
>Loaded: loaded (/lib/systemd/system/capemgr.service; enabled; vendor
> preset: enabled)
>Active: inactive (dead) since Tue 2017-07-11 18:46:54 UTC; 32min ago
>   Process: 4598 ExecStart=/bin/sh /opt/scripts/boot/capemgr.sh (code=exited,
> status=0/SUCCESS)
>  Main PID: 4598 (code=exited, status=0/SUCCESS)
> Jul 11 18:46:53 sim15 systemd[1]: Starting Cape Manager Service...
> Jul 11 18:46:54 sim15 systemd[1]: Started Cape Manager Service.

The BB + Robotic Cape boots a special device tree binary, thus capemgr
is disabled. the librobotic library expects this combination to have
things setup a certain way, as it utilzes /dev/mem to access the
gpio/adc/etc.

As I don't have that cape, and it's still not listed for sale, this
isn't going to change anytime soon.

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/CAOCHtYiZBCje6EnxtZQYxjDeZP1QXCRhpzfno%3DvWrNv%2BcQ8sLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] where is capemgr?

[clarkbriggs101]

After watching the great progress, I started in. I have the 3/19/2017 
latest image with apt-get upgrades running on a Rev C BBB with a Rev C 
Robotics Cape. All in all, the process worked well.  But I can't find 
capemgr. I went looking for it because I want to access analog I/O and 
other stuff. Recent emails from here-ish say capemgr is supposed to be in 
/sys/devices/platform but not.  To get analog I/O, I put 
"cape_enable=bone_capemgr.enable_partno=BB-ADC" in uEnv.txt, but no 
/sys/bus/iio.
some info
debian@sim15:~$ uname -a
Linux sim15 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l 
GNU/Linux
debian@sim15:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2017-03-19
debian@sim15:~$ systemctl status capemgr.service
● capemgr.service - Cape Manager Service
   Loaded: loaded (/lib/systemd/system/capemgr.service; enabled; vendor 
preset: enabled)
   Active: inactive (dead) since Tue 2017-07-11 18:46:54 UTC; 32min ago
  Process: 4598 ExecStart=/bin/sh /opt/scripts/boot/capemgr.sh 
(code=exited, status=0/SUCCESS)
 Main PID: 4598 (code=exited, status=0/SUCCESS)
Jul 11 18:46:53 sim15 systemd[1]: Starting Cape Manager Service...
Jul 11 18:46:54 sim15 systemd[1]: Started Cape Manager Service.

Ideas?
Clark
Clark Briggs
ATA Engineering

-- 
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/87b88838-9b47-4de9-86e5-a0831d27adc5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Remoteproc not loading firmware

[Igor Jędrzejczak]

I don't get it... What I did now is: git pull in dtb-rebuilder; then make 
all_arm and make install_arm - everything successfull; then sudo reboot;

Now whenever I boot the board or I do sudo modprobe pru_rproc - nothing 
happens, there is even no message saying that prus were probed 
successfully...

On Tuesday, 11 July 2017 20:52:06 UTC+2, RobertCNelson wrote:
>
> On Tue, Jul 11, 2017 at 1:36 PM, Igor Jędrzejczak  > wrote: 
> > I also now noticed that there is a message from remoteproc about loading 
> > some elf fw file... Here is my whole dmesg, maybe there is some 
> misconfig 
> > there... 
> > 
> > https://pastebin.com/1HGLkRi2 
>
> The elf file is for the Cortex-M3 which is used for power management. 
>
> 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/9a98ce3f-c20d-4cb3-a0bb-4ef658c473ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Remoteproc not loading firmware

[Robert Nelson]

On Tue, Jul 11, 2017 at 1:36 PM, Igor Jędrzejczak  wrote:
> I also now noticed that there is a message from remoteproc about loading
> some elf fw file... Here is my whole dmesg, maybe there is some misconfig
> there...
>
> https://pastebin.com/1HGLkRi2

The elf file is for the Cortex-M3 which is used for power management.

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/CAOCHtYjSo-1SwG2CyN8r-CwTmSFaoFTsR1suS3QMXtgY3QF8PA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Remoteproc not loading firmware

[Igor Jędrzejczak]

I also now noticed that there is a message from remoteproc about loading 
some elf fw file... Here is my whole dmesg, maybe there is some misconfig 
there...

https://pastebin.com/1HGLkRi2

Thanks for a quick reply

Regards 

On Tuesday, 11 July 2017 20:19:45 UTC+2, Igor Jędrzejczak wrote:
>
> @Robert - tried it, didn't help...
>
> On Tuesday, 11 July 2017 18:15:31 UTC+2, RobertCNelson wrote:
>>
>> On Tue, Jul 11, 2017 at 10:57 AM, Igor Jędrzejczak  
>> wrote: 
>> > 
>> > Hello! 
>> > 
>> > I'm facing an issue with Beaglebone Black PRU. I have successfully 
>> compiled 
>> > a C program for PRU0 and copied it to /lib/firmware with name 
>> > am335x-pru0-fw. But when I type sudo rmmod pru_rproc and then sudo 
>> modprobe 
>> > pru_rproc I see only that both PRUs have been probed successfully, but 
>> there 
>> > is no sign of firmware being loaded. My program doesn't work at all so 
>> it 
>> > seems it hasn't been loaded... I have no idea why that could be. I'm 
>> coming 
>> > back to PRU programming after a while, so this might be I'm missing 
>> > something, but what is this? 
>> > 
>> > My kernel is 4.9.36 ti rt 
>> > 
>> > Dmesg output: 
>> > [  361.101046] pru-rproc 4a338000.pru1: pru_rproc_remove: removing 
>> rproc 
>> > 4a338000.pru1 
>> > [  361.113437] remoteproc remoteproc2: releasing 4a338000.pru1 
>> > [  361.113740] pru-rproc 4a334000.pru0: pru_rproc_remove: removing 
>> rproc 
>> > 4a334000.pru0 
>> > [  361.114703] remoteproc remoteproc1: releasing 4a334000.pru0 
>> > [  365.601110] remoteproc remoteproc1: 4a334000.pru0 is available 
>> > [  365.601329] pru-rproc 4a334000.pru0: PRU rproc node 
>> > /ocp/pruss_soc_bus@4a326000/pruss@4a30/pru@4a334000 probed 
>> successfully 
>> > [  365.608375] remoteproc remoteproc2: 4a338000.pru1 is available 
>> > [  365.608639] pru-rproc 4a338000.pru1: PRU rproc node 
>> > /ocp/pruss_soc_bus@4a326000/pruss@4a30/pru@4a338000 probed 
>> successfully 
>> > 
>> > 
>> > My uEnv file in /boot: 
>> > uname_r=4.9.36-ti-rt-r45 
>> > uuid=0e71d59c-6852-49b0-92b3-1769eaed1c2e 
>> > dtb=am335x-boneblack-emmc-overlay.dtb 
>>
>> it might not see the firmware.. 
>>
>> sudo update-initramfs -uk `uname -r` 
>>
>> sudo reboot 
>>
>> 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/a095aabf-0948-42c7-bdfb-6739b8826d26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Remoteproc not loading firmware

[Igor Jędrzejczak]

@Robert - tried it, didn't help...

On Tuesday, 11 July 2017 18:15:31 UTC+2, RobertCNelson wrote:
>
> On Tue, Jul 11, 2017 at 10:57 AM, Igor Jędrzejczak  > wrote: 
> > 
> > Hello! 
> > 
> > I'm facing an issue with Beaglebone Black PRU. I have successfully 
> compiled 
> > a C program for PRU0 and copied it to /lib/firmware with name 
> > am335x-pru0-fw. But when I type sudo rmmod pru_rproc and then sudo 
> modprobe 
> > pru_rproc I see only that both PRUs have been probed successfully, but 
> there 
> > is no sign of firmware being loaded. My program doesn't work at all so 
> it 
> > seems it hasn't been loaded... I have no idea why that could be. I'm 
> coming 
> > back to PRU programming after a while, so this might be I'm missing 
> > something, but what is this? 
> > 
> > My kernel is 4.9.36 ti rt 
> > 
> > Dmesg output: 
> > [  361.101046] pru-rproc 4a338000.pru1: pru_rproc_remove: removing rproc 
> > 4a338000.pru1 
> > [  361.113437] remoteproc remoteproc2: releasing 4a338000.pru1 
> > [  361.113740] pru-rproc 4a334000.pru0: pru_rproc_remove: removing rproc 
> > 4a334000.pru0 
> > [  361.114703] remoteproc remoteproc1: releasing 4a334000.pru0 
> > [  365.601110] remoteproc remoteproc1: 4a334000.pru0 is available 
> > [  365.601329] pru-rproc 4a334000.pru0: PRU rproc node 
> > /ocp/pruss_soc_bus@4a326000/pruss@4a30/pru@4a334000 probed 
> successfully 
> > [  365.608375] remoteproc remoteproc2: 4a338000.pru1 is available 
> > [  365.608639] pru-rproc 4a338000.pru1: PRU rproc node 
> > /ocp/pruss_soc_bus@4a326000/pruss@4a30/pru@4a338000 probed 
> successfully 
> > 
> > 
> > My uEnv file in /boot: 
> > uname_r=4.9.36-ti-rt-r45 
> > uuid=0e71d59c-6852-49b0-92b3-1769eaed1c2e 
> > dtb=am335x-boneblack-emmc-overlay.dtb 
>
> it might not see the firmware.. 
>
> sudo update-initramfs -uk `uname -r` 
>
> sudo reboot 
>
> 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/ff88820e-a436-4a01-b574-3577113af2cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] uboot, saveenv and what works

[Jeff Andich]

Thanks Robert !

Looks like someone using yocto for BBB also had a similar question a couple 
years 
ago, https://lists.yoctoproject.org/pipermail/yocto/2015-April/024636.html...



On Tuesday, July 11, 2017 at 11:59:37 AM UTC-5, RobertCNelson wrote:
>
> On Sun, Jul 9, 2017 at 10:53 AM, marty leisner  > wrote: 
> > Different postings seem to indicate different things. 
> > 
> > I've been using u-boot for over a decade and I'm used to the 
> saveenv/fw_* 
> > tools. 
> > 
> > Seems the default beagles don't support this.   I have a older 2G eMMC 
> and a 
> > newer 4G eMMC beagle -- I just built uboot and that and the distributed 
> one 
> > don't have saveenv present. 
> > 
> > The uboot I built was from the instructions here: 
> > 
> https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot
>  
> > 
> > 
> > But this posting: 
> > 
> > https://e2e.ti.com/support/embedded/linux/f/354/t/425207 
> > 
> > talks about fw_* tools and saveenv. 
> > 
> > I'm slightly confused. 
>
> saveenv is disabled as it breaks the BeagleBone White (no eMMC) 
>
> you can easily re-enable by removing this change: 
>
>
> https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2017.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L250
>  
>
> 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/e6907e00-955a-4825-89c4-cd157b34834b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] uboot, saveenv and what works

[Robert Nelson]

On Sun, Jul 9, 2017 at 10:53 AM, marty leisner  wrote:
> Different postings seem to indicate different things.
>
> I've been using u-boot for over a decade and I'm used to the saveenv/fw_*
> tools.
>
> Seems the default beagles don't support this.   I have a older 2G eMMC and a
> newer 4G eMMC beagle -- I just built uboot and that and the distributed one
> don't have saveenv present.
>
> The uboot I built was from the instructions here:
> https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot
>
>
> But this posting:
>
> https://e2e.ti.com/support/embedded/linux/f/354/t/425207
>
> talks about fw_* tools and saveenv.
>
> I'm slightly confused.

saveenv is disabled as it breaks the BeagleBone White (no eMMC)

you can easily re-enable by removing this change:

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2017.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L250

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/CAOCHtYib%2BDdWLdTZFAuxNM5uLXMgUJbAW2E2jK-KiBHwN%3DgnJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: uboot, saveenv and what works

[Jeff Andich]

I THINK I have the same/similar question.  Given the 
BeagleBone/BeagleBoard's single ext4 partition strategy for containing the 
FS and kernel and where u-boot/MLO is copied into the the "hole" below the 
partition table using the dd command, where is the default and user-updated 
u-boot environment saved now?

I have an SD Card for the TI SDK for the 572xEVM which has 2 partitions, 
(1) boot and (2) rootfs.  I believe in TI SDK land, the u-boot environment 
variables are saved to uboot.env in the boot partition. Thanks!!


On Sunday, July 9, 2017 at 10:54:20 AM UTC-5, Marty Leisner wrote:

> Different postings seem to indicate different things.
>
> I've been using u-boot for over a decade and I'm used to the saveenv/fw_* 
> tools.
>
> Seems the default beagles don't support this.   I have a older 2G eMMC and 
> a newer 4G eMMC beagle -- I just built uboot and that and the distributed 
> one don't have saveenv present.
>
> The uboot I built was from the instructions here:
>
> https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot
>
>
> But this posting:
>
> https://e2e.ti.com/support/embedded/linux/f/354/t/425207
>
> talks about fw_* tools and saveenv.
>
> I'm slightly confused.
>
> marty
>

-- 
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/4f0a08da-3cce-42af-b985-49370d674386%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Remoteproc not loading firmware

[Robert Nelson]

On Tue, Jul 11, 2017 at 10:57 AM, Igor Jędrzejczak  wrote:
>
> Hello!
>
> I'm facing an issue with Beaglebone Black PRU. I have successfully compiled
> a C program for PRU0 and copied it to /lib/firmware with name
> am335x-pru0-fw. But when I type sudo rmmod pru_rproc and then sudo modprobe
> pru_rproc I see only that both PRUs have been probed successfully, but there
> is no sign of firmware being loaded. My program doesn't work at all so it
> seems it hasn't been loaded... I have no idea why that could be. I'm coming
> back to PRU programming after a while, so this might be I'm missing
> something, but what is this?
>
> My kernel is 4.9.36 ti rt
>
> Dmesg output:
> [  361.101046] pru-rproc 4a338000.pru1: pru_rproc_remove: removing rproc
> 4a338000.pru1
> [  361.113437] remoteproc remoteproc2: releasing 4a338000.pru1
> [  361.113740] pru-rproc 4a334000.pru0: pru_rproc_remove: removing rproc
> 4a334000.pru0
> [  361.114703] remoteproc remoteproc1: releasing 4a334000.pru0
> [  365.601110] remoteproc remoteproc1: 4a334000.pru0 is available
> [  365.601329] pru-rproc 4a334000.pru0: PRU rproc node
> /ocp/pruss_soc_bus@4a326000/pruss@4a30/pru@4a334000 probed successfully
> [  365.608375] remoteproc remoteproc2: 4a338000.pru1 is available
> [  365.608639] pru-rproc 4a338000.pru1: PRU rproc node
> /ocp/pruss_soc_bus@4a326000/pruss@4a30/pru@4a338000 probed successfully
>
>
> My uEnv file in /boot:
> uname_r=4.9.36-ti-rt-r45
> uuid=0e71d59c-6852-49b0-92b3-1769eaed1c2e
> dtb=am335x-boneblack-emmc-overlay.dtb

it might not see the firmware..

sudo update-initramfs -uk `uname -r`

sudo reboot

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

[beagleboard] Re: Max14830, uart over spi, device tree overlay/kernel driver

[Jeff Andich]

We just received a Maxim 3107 evaluation board and WERE planning on 
interfacing it to the BeagleBoard-X15 to try to bring up extra UART ports 
over SPI/I2C on the BBX15, but then we found the room for a USB hub in 
place of the Maxim chips on our custom board.  Nonetheless, if there's 
anything you would like me (as a Linux newbie) to try on this setup 
(BBX15<->Maxim 3107 EVM) I will try to get around to it as a side 
project  Thanks!



On Tuesday, July 11, 2017 at 7:13:30 AM UTC-5, sbha...@gmail.com wrote:
>
> Hi,
>
> Did you got this working ? If so please can you post the solution.
>
> On Wednesday, 20 July 2016 18:43:34 UTC+5:30, Laurits Telle Riple wrote:
>>
>> I am trying to get MAX14830 
>> 
>>  
>> to work with beaglebone black using max310x 
>> driver
>>  
>> over spi. With my dts, the overlay gets loaded, but i dont get any new 
>> devices in /dev.  With my oscilloscope i can see that nothing happens and 
>> that CS is low (Active low, so something is wrong). I dont understand what 
>> I am doing wrong. I have the chip connected to a 4Mhz external crystal.
>>
>> Output from dmesg after loading manually:
>>
>> [  212.403551] bone_capemgr bone_capemgr: part_number 'BB-MAX14830-01', 
>> version 'N/A'
>> [  212.411232] bone_capemgr bone_capemgr: slot #6: override
>> [  212.416720] bone_capemgr bone_capemgr: Using override eeprom data at 
>> slot 6
>> [  212.423786] bone_capemgr bone_capemgr: slot #6: 'Override Board 
>> Name,00A0,Override Manuf,BB-MAX14830-01'
>> [  212.461917] bone_capemgr bone_capemgr: slot #6: dtbo 
>> 'BB-MAX14830-01-00A0.dtbo' loaded; overlay id #0
>>
>> modalias:
>>
>> debian@arm:~$ cat /sys/bus/spi/devices/*/modalias
>> spi:max14830
>>
>>
>> DTS:
>>
>> /dts-v1/;
>> /plugin/;
>>
>>
>> / {
>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>> part-number = "BB-MAX14830-01";
>>
>> /* state the resources this cape uses */
>> exclusive-use =
>> /* the pin header uses */
>> "P9.25",/* spi irq: gpio3_21 */
>> "P9.31",/* spi: spi1_sclk */
>> "P9.29",/* spi: spi1_d0 */
>> "P9.30",/* spi: spi1_d1 */
>> "P9.28",/* spi: spi1_cs0 */
>> /* the hardware IP uses */
>> "gpio3_21",
>> "spi1";
>>
>> fragment@0 {
>> target = <_pinmux>;
>> __overlay__ {
>> bone_14830_spi1_pins: pinmux_bone_14830_spi1_pins {
>> pinctrl-single,pins = <
>> 0x190 0x33  /* 
>> mcasp0_aclkx.spi1_sclk, RX_ENABLED | PULLUP | MODE3 */
>> 0x194 0x33  /* 
>> mcasp0_fsx.spi1_d0, RX_ENABLED | PULLUP | MODE3 */
>> 0x198 0x13  /* 
>> mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
>> 0x19c 0x13  /* 
>> mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
>> >;
>> };
>>
>> bone_14830_pins: pinmux_bone_14830_pins {
>> pinctrl-single,pins = <
>> 0x1ac 0x37  /* 
>> mcasp0_ahclkx.gpio3_21, RX_ENABLED | PULLUP | MODE7 */
>> >;
>> };
>> };
>> };
>>
>> fragment@1 {
>>   target = <>;
>> __overlay__ {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> status= "okay";
>> pinctrl-names   = "default";
>> pinctrl-0   = <_14830_spi1_pins>;
>> max14830@0 {
>> compatible = "maxim,max14830";
>> reg = <0>; /* cs0 */
>> mode=<0>;
>> spi-max-frequency=<100>;
>>
>> pinctrl-names="default";
>> pinctrl-0 = <_14830_pins>;
>> clocks=<>;
>> clock-names="xtal";
>> interrupt-parent = <>;
>> interrupts = <21 2>; // Edge Falling
>>
>> clk4m: clk4m@10 {
>> compatible = "fixed-clock";
>> #clock-cells = <0>;
>> clock-frequency = <400>;
>> };
>> };

[beagleboard] Remoteproc not loading firmware

[Igor Jędrzejczak]

Hello!

I'm facing an issue with Beaglebone Black PRU. I have successfully compiled 
a C program for PRU0 and copied it to /lib/firmware with name 
am335x-pru0-fw. But when I type sudo rmmod pru_rproc and then sudo modprobe 
pru_rproc I see only that both PRUs have been probed successfully, but 
there is no sign of firmware being loaded. My program doesn't work at all 
so it seems it hasn't been loaded... I have no idea why that could be. I'm 
coming back to PRU programming after a while, so this might be I'm missing 
something, but what is this?

My kernel is 4.9.36 ti rt

Dmesg output:
[  361.101046] pru-rproc 4a338000.pru1: pru_rproc_remove: removing rproc 
4a338000.pru1
[  361.113437] remoteproc remoteproc2: releasing 4a338000.pru1
[  361.113740] pru-rproc 4a334000.pru0: pru_rproc_remove: removing rproc 
4a334000.pru0
[  361.114703] remoteproc remoteproc1: releasing 4a334000.pru0
[  365.601110] remoteproc remoteproc1: 4a334000.pru0 is available
[  365.601329] pru-rproc 4a334000.pru0: PRU rproc node 
/ocp/pruss_soc_bus@4a326000/pruss@4a30/pru@4a334000 probed successfully
[  365.608375] remoteproc remoteproc2: 4a338000.pru1 is available
[  365.608639] pru-rproc 4a338000.pru1: PRU rproc node 
/ocp/pruss_soc_bus@4a326000/pruss@4a30/pru@4a338000 probed successfully


My uEnv file in /boot:
uname_r=4.9.36-ti-rt-r45
uuid=0e71d59c-6852-49b0-92b3-1769eaed1c2e
dtb=am335x-boneblack-emmc-overlay.dtb


Best regards
Igor

-- 
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/b56086f4-0d51-4f38-9f20-bdc53c7c9517%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How to convert multiple raw images to qcow2?

[sandip divekar]

I have created 1 VM in qemu using 2 raw images, which has 2 partitions as 
given below.

/dev/sda1   910G  263G  601G  31% /
/dev/sdb   5G  1G  4G  20% /mnt

Then I am stopping the VM and converting both raw images to qcow2 format. 
Using these qcow2 images I am trying to launch a new vm. But vm is not 
loading properly, its going in rescue mode. Is it possible to convert 
multiple raw to qcow2 images?

-- 
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/45528183-f4fa-4f6c-8ab4-5857c8641371%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Right way to configure ID EEPROM on new cape?

[gaurav . sureka]

In addition to Robert's response, here is a second (though somewhat 
outdated) page and associated links that show how to write to eeprom of a 
custom cape.

https://github.com/jbdatko/eeprom_tutorial/blob/master/eeprom.md

Note: some of the information on this page is old stuff, for example the 
i2c channels used. Verify with your kernel version.

Hope this helps,
Gaurav

On Sunday, July 9, 2017 at 2:46:25 PM UTC-5, s...@cloud9.net wrote:
>
> Hi Guys,
>
> Lurker here.  I have been working on developing audio capes for the 
> Beaglebone Black.  I now have a design I am poised to ship.  First, 
> however, I need to know the right thing to do with the cape's EEPROM so it 
> works "out of the box" for users.
>
> I believe the EEPROM is read by the BBB during boot, and the info in the 
> EEPROM helps the BBB load the correct device tree overlay, right?
>
> Can one of the experts on this list please point me to a HOWTO or other 
> documentation which describes how to put the correct ID into the EEPROM so 
> the BBB knows what to do with the associated cape?  Some info about where 
> to stage the cape's .dtbo file so it is loaded during boot would also be 
> appreciated.
>
> Thanks for any pointers you have,
> Stuart
>
>

-- 
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/f25f9afb-0483-48a7-892a-34bc201b689b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Max14830, uart over spi, device tree overlay/kernel driver

[sbharsha]

Hi,

Did you got this working ? If so please can you post the solution.

On Wednesday, 20 July 2016 18:43:34 UTC+5:30, Laurits Telle Riple wrote:
>
> I am trying to get MAX14830 
> 
>  
> to work with beaglebone black using max310x 
> driver
>  
> over spi. With my dts, the overlay gets loaded, but i dont get any new 
> devices in /dev.  With my oscilloscope i can see that nothing happens and 
> that CS is low (Active low, so something is wrong). I dont understand what 
> I am doing wrong. I have the chip connected to a 4Mhz external crystal.
>
> Output from dmesg after loading manually:
>
> [  212.403551] bone_capemgr bone_capemgr: part_number 'BB-MAX14830-01', 
> version 'N/A'
> [  212.411232] bone_capemgr bone_capemgr: slot #6: override
> [  212.416720] bone_capemgr bone_capemgr: Using override eeprom data at 
> slot 6
> [  212.423786] bone_capemgr bone_capemgr: slot #6: 'Override Board 
> Name,00A0,Override Manuf,BB-MAX14830-01'
> [  212.461917] bone_capemgr bone_capemgr: slot #6: dtbo 
> 'BB-MAX14830-01-00A0.dtbo' loaded; overlay id #0
>
> modalias:
>
> debian@arm:~$ cat /sys/bus/spi/devices/*/modalias
> spi:max14830
>
>
> DTS:
>
> /dts-v1/;
> /plugin/;
>
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
> part-number = "BB-MAX14830-01";
>
> /* state the resources this cape uses */
> exclusive-use =
> /* the pin header uses */
> "P9.25",/* spi irq: gpio3_21 */
> "P9.31",/* spi: spi1_sclk */
> "P9.29",/* spi: spi1_d0 */
> "P9.30",/* spi: spi1_d1 */
> "P9.28",/* spi: spi1_cs0 */
> /* the hardware IP uses */
> "gpio3_21",
> "spi1";
>
> fragment@0 {
> target = <_pinmux>;
> __overlay__ {
> bone_14830_spi1_pins: pinmux_bone_14830_spi1_pins {
> pinctrl-single,pins = <
> 0x190 0x33  /* 
> mcasp0_aclkx.spi1_sclk, RX_ENABLED | PULLUP | MODE3 */
> 0x194 0x33  /* 
> mcasp0_fsx.spi1_d0, RX_ENABLED | PULLUP | MODE3 */
> 0x198 0x13  /* 
> mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
> 0x19c 0x13  /* 
> mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
> >;
> };
>
> bone_14830_pins: pinmux_bone_14830_pins {
> pinctrl-single,pins = <
> 0x1ac 0x37  /* 
> mcasp0_ahclkx.gpio3_21, RX_ENABLED | PULLUP | MODE7 */
> >;
> };
> };
> };
>
> fragment@1 {
>   target = <>;
> __overlay__ {
> #address-cells = <1>;
> #size-cells = <0>;
> status= "okay";
> pinctrl-names   = "default";
> pinctrl-0   = <_14830_spi1_pins>;
> max14830@0 {
> compatible = "maxim,max14830";
> reg = <0>; /* cs0 */
> mode=<0>;
> spi-max-frequency=<100>;
>
> pinctrl-names="default";
> pinctrl-0 = <_14830_pins>;
> clocks=<>;
> clock-names="xtal";
> interrupt-parent = <>;
> interrupts = <21 2>; // Edge Falling
>
> clk4m: clk4m@10 {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <400>;
> };
> };
> };
> };
> };
>
>  
>
>  
>
>
>
>

-- 
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/0932465a-1471-4a52-8b48-93d013b918b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: GPIO configuartion in Device Tree Overlay and how to set a default value for an output pin

[Beagle Boner]

Well I did a little workaround and made a script that will init the GPIO 
via sysfs in the way I want at system start. But I don´t need to set the 
pinmux via the overlay for that as far as i know.
echo "61" > /sys/class/gpio/export   #set gpio61 P8_26
echo "out" > /sys/class/gpio/gpio61/direction#set gpio61 as output
echo "1" > /sys/class/gpio/gpio61/value  #set gpio61 to high

The fragment@1 I mentioned seems to affect 
/sys/kernel/debug/pinctrl
But I still dont understand what it actually does.

-- 
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/56bd9ec5-ba9b-4bcc-aa75-2364397755ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.