Re: [beagleboard] My overlay can't find clk_mcasp0

[Rick Mann]

Good news! Thanks for all the work.

> On Apr 21, 2016, at 23:41 , William Hermans  wrote:
> 
> Progress. I was able to get teh audio cape to load in 4.1.x.
> 
> william@beaglebone:~$ sudo sh -c "echo 'BB-BONE-AUDI-02' > 
> /sys/devices/platform/bone_capemgr/slots"
> [  104.123082] bone_capemgr bone_capemgr: part_number 'BB-BONE-AUDI-02', 
> version 'N/A'
> [  104.130898] bone_capemgr bone_capemgr: slot #4: override
> [  104.136277] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
> [  104.143283] bone_capemgr bone_capemgr: slot #4: 'Override Board 
> Name,00A0,Override Manuf,BB-BONE-AUDI-02'
> [  104.157826] bone_capemgr bone_capemgr: slot #4: dtbo 
> 'BB-BONE-AUDI-02-00A0.dtbo' loaded; overlay id #0
> [  104.311953] 2-0018 supply IOVDD not found, using dummy regulator
> [  104.318146] 2-0018 supply DVDD not found, using dummy regulator
> [  104.324235] 2-0018 supply AVDD not found, using dummy regulator
> [  104.330270] 2-0018 supply DRVDD not found, using dummy regulator
> [  104.339740] asoc-simple-card sound: tlv320aic3x-hifi <-> 48038000.mcasp 
> mapping ok
> 
> I used your device tree board file exactly Rick, with one modification.
> 
> #include "am33xx.dtsi"
> #include "am335x-bone-common.dtsi"
> 
> 
> The other two includes were removed. The rest of your source file is exactly 
> the same. But the am33xx-es2.dtsi include 
> file looked pretty much useless to me for this end goal. Looked like it had 
> mostly to do with voltage / processor frequency 
> scaling. Since I did not know if that was a 4.4.x specific feature, I just 
> removed the include. 
> 
> /*
>  * Device Tree Source for AM33XX SoC
>  *
>  * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>  *
>  * This file is licensed under the terms of the GNU General Public License
>  * version 2.  This program is licensed "as is" without any warranty of any
>  * kind, whether express or implied.
>  */
> 
> / {
>   cpus {
>   cpu@0 {
>   /*
>* To consider voltage drop between PMIC and SoC,
>* tolerance value is reduced to 2% from 4% and
>* voltage value is increased as a precaution.
>*/
>   operating-points = <
>   /* kHzuV */
>   100 1325000
>   80  130
>   60  1112000
>   30  969000
>   >;
>   voltage-tolerance = <2>; /* 2 percentage */
> 
>   clocks = <&dpll_mpu_ck>;
>   clock-names = "cpu";
> 
>   clock-latency = <30>; /* From omap-cpufreq driver */
>   };
>   };
> };
> 
> On Thu, Apr 21, 2016 at 2:51 PM, Rick Mann  wrote:
> I don't have the BBB connected at the moment, but if I don't get you the 
> configuration by tonight, please feel free to email me again.
> 
> > On Apr 21, 2016, at 14:40 , Rafael Vega  wrote:
> >
> > I've made some progress but I still can't get any sound from the codec. I 
> > tried the two approaches suggested by Rick M earlier on this thread:
> >
> > 1) To use this dtb by Rick M and the audio cape overlay, and 2) to use this 
> > dtb (by RobertCNelson) with no overlay. In both cases I have the same 
> > apparent outcome: I can see I2C and I2S signals being driven by the BBB 
> > when I use aplay or speaker-test but I can't see any analog signal coming 
> > out of the codec.
> >
> > I have played around with alsamixer, I have deleted 
> > /var/lib/alsa/asound.state, used the one from here and no luck...
> >
> > I guess the next step would be to check the driver code and the codec 
> > datasheet to try to figure out what might be wrong. I found the code for 
> > the driver here (is that it?) but I have no experience in kernel-land 
> > development so I'm not sure what the compiling/debugging workflow would 
> > be...  My initial questions are:
> >
> > 1. How do you compile and install the driver/module without recompiling and 
> > installing the whole kernel?
> > 2. How does the driver code integrates with the device tree system? I can't 
> > see anyting in the driver code that suggests it's taking values or it's 
> > functions are being called from the dtb or the overlay.
> > 3. What is the simplest 'log' function callable from kernel land and where 
> > do I see the output?
> >
> > Any advice on  this would be appreciated!
> >
> > :)
> >
> > --
> > For more options, visit http://beagleboard.org/discuss
> > ---
> > You received this message because you are subscribed to the Google Groups 
> > "BeagleBoard" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to beagleboard+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/beagleboard/78d35232-c66d-4

Re: [beagleboard] Fundamental capemanager change between 4.1.x, and 4.4.x

[William Hermans]

Yeah, IDK, I'm beat for the night, but in my humble opinion, this is a show
stopper. 4.4.x is not ready yet. Maybe tomorrow when better rested I'll be
able to think of something else to test. In hopes of getting this fixed /
resolved.

On Thu, Apr 21, 2016 at 11:02 PM, William Hermans  wrote:

> It's not the device tree node which is in the include *am33xx.dtsi*, they
> both seem to be exactly the same.
>
> tscadc: tscadc@44e0d000 {
> compatible = "ti,am3359-tscadc";
> reg = <0x44e0d000 0x1000>;
> interrupt-parent = <&intc>;
> interrupts = <16>;
> ti,hwmods = "adc_tsc";
> status = "disabled";
>
> tsc {
> compatible = "ti,am3359-tsc";
> };
> am335x_adc: adc {
> #io-channel-cells = <1>;
> compatible = "ti,am3359-adc";
> };
> };
>
> On Thu, Apr 21, 2016 at 9:58 PM, William Hermans 
> wrote:
>
>> Just for added measure, yes the UIO driver does work . .
>>
>> william@beaglebone:~$ lsuio
>> uio0: name=tscadc, version=devicetree, events=0
>> map[0]: addr=0x44E0D000, size=4096
>>
>>
>> On Thu, Apr 21, 2016 at 9:51 PM, William Hermans 
>> wrote:
>>
>>> Ok, so the following does *NOT* work on a 4.4.x kernel, but does on a
>>> 4.1.x kernel.
>>>
>>> *Starting off with 4.4.x kernel*
>>>
>>> william@beaglebone:~$ cat ti/WH-ADC-00A0.dts
>>>
>>>
>>> /dts-v1/;
>>> /plugin/;
>>>
>>> / {
>>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>>>
>>> /* identification */
>>> part-number = "WH-ADC";
>>> version = "00A0";
>>>
>>>
>>> fragment@0 {
>>> target = <&tscadc>;
>>> __overlay__ {
>>> compatible = "uio";
>>> uio-alias = "adc";
>>> status = "okay";
>>> };
>>> };
>>> };
>>>
>>>
>>>
>>> william@beaglebone:~$ sudo touch /etc/modprobe.d/uio.conf
>>> william@beaglebone:~$ sudo nano /etc/modprobe.d/uio.conf
>>> # put in /etc/modprobe.d/uio.conf
>>> #
>>> # make driver match on  compatible = "uio";
>>> options uio_pdrv_genirq of_id=uio
>>>
>>> william@beaglebone:~$ ls /dev | grep uio /* Crickets . . .*/
>>>
>>> william@beaglebone:~$ sudo sh -c "echo ' WH-ADC' >
>>> /sys/devices/platform/bone_capemgr/slots"
>>> [ 3658.413635] bone_capemgr bone_capemgr: part_number ' WH-ADC',
>>> version 'N/A'
>>> [ 3658.420830] bone_capemgr bone_capemgr: slot #5: override
>>> [ 3658.426181] bone_capemgr bone_capemgr: Using override eeprom data at
>>> slot 5
>>> [ 3658.433959] bone_capemgr bone_capemgr: slot #5: 'Override Board
>>> Name,00A0,Override Manuf, WH-ADC'
>>>
>>> *Changing to 4.1.x kernel*
>>>
>>> william@beaglebone:~$ sudo nano /boot/uEnv.txt
>>> uname_r=4.1.18-bone-rt-r19
>>> william@beaglebone:~$ sudo reboot
>>>
>>> william@beaglebone:~$ sudo sh -c "echo 'WH-ADC' >
>>> /sys/devices/platform/bone_capemgr/slots"
>>> [   62.607962] bone_capemgr bone_capemgr: part_number 'WH-ADC', version
>>> 'N/A'
>>> [   62.614993] bone_capemgr bone_capemgr: slot #4: override
>>> [   62.620338] bone_capemgr bone_capemgr: Using override eeprom data at
>>> slot 4
>>> [   62.627374] bone_capemgr bone_capemgr: slot #4: 'Override Board
>>> Name,00A0,Override Manuf,WH-ADC'
>>> [   62.649771] bone_capemgr bone_capemgr: slot #4: dtbo
>>> 'WH-ADC-00A0.dtbo' loaded; overlay id #0
>>>
>>> So, something between these two versions, has changed, and has broken
>>> what worked initially. Perhaps it could even be the adc alias in the main
>>> board file ? I haven't looked yet . . .
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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/7504f115-e242-4617-b956-d4549aeeb029%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/CALHSORqo0kHHkbyNoCiOSHW_J6OsTwOa6_wCQqQ9GUX7d-cg7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[William Hermans]

Progress. I was able to get teh audio cape to load in 4.1.x.

william@beaglebone:~$ sudo sh -c "echo 'BB-BONE-AUDI-02' >
/sys/devices/platform/bone_capemgr/slots"
[  104.123082] bone_capemgr bone_capemgr: part_number 'BB-BONE-AUDI-02',
version 'N/A'
[  104.130898] bone_capemgr bone_capemgr: slot #4: override
[  104.136277] bone_capemgr bone_capemgr: Using override eeprom data at
slot 4
[  104.143283] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-BONE-AUDI-02'
[  104.157826] bone_capemgr bone_capemgr: slot #4: dtbo
'BB-BONE-AUDI-02-00A0.dtbo' loaded; overlay id #0
[  104.311953] 2-0018 supply IOVDD not found, using dummy regulator
[  104.318146] 2-0018 supply DVDD not found, using dummy regulator
[  104.324235] 2-0018 supply AVDD not found, using dummy regulator
[  104.330270] 2-0018 supply DRVDD not found, using dummy regulator
[  104.339740] asoc-simple-card sound: tlv320aic3x-hifi <-> 48038000.mcasp
mapping ok

I used your device tree board file exactly Rick, with one modification.

#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"

The other two includes were removed. The rest of your source file is
exactly the same. But the am33xx-es2.dtsi include
file looked pretty much useless to me for this end goal. Looked like
it had mostly to do with voltage / processor frequency
scaling. Since I did not know if that was a 4.4.x specific feature, I
just removed the include.

/*
 * Device Tree Source for AM33XX SoC
 *
 * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 *
 * This file is licensed under the terms of the GNU General Public License
 * version 2.  This program is licensed "as is" without any warranty of any
 * kind, whether express or implied.
 */

/ {
cpus {
cpu@0 {
/*
 * To consider voltage drop between PMIC and SoC,
 * tolerance value is reduced to 2% from 4% and
 * voltage value is increased as a precaution.
 */
operating-points = <
/* kHzuV */
100 1325000
80  130
60  1112000
30  969000
>;
voltage-tolerance = <2>; /* 2 percentage */

clocks = <&dpll_mpu_ck>;
clock-names = "cpu";

clock-latency = <30>; /* From omap-cpufreq driver */
};
};
};


On Thu, Apr 21, 2016 at 2:51 PM, Rick Mann  wrote:

> I don't have the BBB connected at the moment, but if I don't get you the
> configuration by tonight, please feel free to email me again.
>
> > On Apr 21, 2016, at 14:40 , Rafael Vega  wrote:
> >
> > I've made some progress but I still can't get any sound from the codec.
> I tried the two approaches suggested by Rick M earlier on this thread:
> >
> > 1) To use this dtb by Rick M and the audio cape overlay, and 2) to use
> this dtb (by RobertCNelson) with no overlay. In both cases I have the same
> apparent outcome: I can see I2C and I2S signals being driven by the BBB
> when I use aplay or speaker-test but I can't see any analog signal coming
> out of the codec.
> >
> > I have played around with alsamixer, I have deleted
> /var/lib/alsa/asound.state, used the one from here and no luck...
> >
> > I guess the next step would be to check the driver code and the codec
> datasheet to try to figure out what might be wrong. I found the code for
> the driver here (is that it?) but I have no experience in kernel-land
> development so I'm not sure what the compiling/debugging workflow would
> be...  My initial questions are:
> >
> > 1. How do you compile and install the driver/module without recompiling
> and installing the whole kernel?
> > 2. How does the driver code integrates with the device tree system? I
> can't see anyting in the driver code that suggests it's taking values or
> it's functions are being called from the dtb or the overlay.
> > 3. What is the simplest 'log' function callable from kernel land and
> where do I see the output?
> >
> > Any advice on  this would be appreciated!
> >
> > :)
> >
> > --
> > For more options, visit http://beagleboard.org/discuss
> > ---
> > You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/78d35232-c66d-49e8-841c-f77f99e5e368%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message

[beagleboard] Chipsee LCD 7 EXP R on Beaglebone Black

[Victor WANG]

Hello，

I tried to use *Chipsee LCD 7 EXP R* as a screen of my BBB (the OS is : *Linux 
beaglebone 4.1.15-ti-rt-r43 #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC 2016 
armv7l GNU/Linux*), 
I did *sudo sed -i -e 's:16:24:g' /etc/X11/xorg.conf *and changed 
*dtb=am335x-boneblack-bbb-exp-r.dtb*  in  /boot/uEnv.txt, ( by the 
introduction of : 
http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Chipsee_bbb-exp-r ).
But the result is wired, I can light the screen but without anything 
display, which means the screen is always light with empty content. 

There must be something wrong in my process, but I have no idea to correct 
it, Thanks so much for any advice.

Best regards,

Victor

-- 
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/f3ac939f-d72f-4593-a3bf-7cdbd871ef1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Fundamental capemanager change between 4.1.x, and 4.4.x

[William Hermans]

It's not the device tree node which is in the include *am33xx.dtsi*, they
both seem to be exactly the same.

tscadc: tscadc@44e0d000 {
compatible = "ti,am3359-tscadc";
reg = <0x44e0d000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <16>;
ti,hwmods = "adc_tsc";
status = "disabled";

tsc {
compatible = "ti,am3359-tsc";
};
am335x_adc: adc {
#io-channel-cells = <1>;
compatible = "ti,am3359-adc";
};
};

On Thu, Apr 21, 2016 at 9:58 PM, William Hermans  wrote:

> Just for added measure, yes the UIO driver does work . .
>
> william@beaglebone:~$ lsuio
> uio0: name=tscadc, version=devicetree, events=0
> map[0]: addr=0x44E0D000, size=4096
>
>
> On Thu, Apr 21, 2016 at 9:51 PM, William Hermans 
> wrote:
>
>> Ok, so the following does *NOT* work on a 4.4.x kernel, but does on a
>> 4.1.x kernel.
>>
>> *Starting off with 4.4.x kernel*
>>
>> william@beaglebone:~$ cat ti/WH-ADC-00A0.dts
>>
>>
>> /dts-v1/;
>> /plugin/;
>>
>> / {
>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>>
>> /* identification */
>> part-number = "WH-ADC";
>> version = "00A0";
>>
>>
>> fragment@0 {
>> target = <&tscadc>;
>> __overlay__ {
>> compatible = "uio";
>> uio-alias = "adc";
>> status = "okay";
>> };
>> };
>> };
>>
>>
>>
>> william@beaglebone:~$ sudo touch /etc/modprobe.d/uio.conf
>> william@beaglebone:~$ sudo nano /etc/modprobe.d/uio.conf
>> # put in /etc/modprobe.d/uio.conf
>> #
>> # make driver match on  compatible = "uio";
>> options uio_pdrv_genirq of_id=uio
>>
>> william@beaglebone:~$ ls /dev | grep uio /* Crickets . . .*/
>>
>> william@beaglebone:~$ sudo sh -c "echo ' WH-ADC' >
>> /sys/devices/platform/bone_capemgr/slots"
>> [ 3658.413635] bone_capemgr bone_capemgr: part_number ' WH-ADC', version
>> 'N/A'
>> [ 3658.420830] bone_capemgr bone_capemgr: slot #5: override
>> [ 3658.426181] bone_capemgr bone_capemgr: Using override eeprom data at
>> slot 5
>> [ 3658.433959] bone_capemgr bone_capemgr: slot #5: 'Override Board
>> Name,00A0,Override Manuf, WH-ADC'
>>
>> *Changing to 4.1.x kernel*
>>
>> william@beaglebone:~$ sudo nano /boot/uEnv.txt
>> uname_r=4.1.18-bone-rt-r19
>> william@beaglebone:~$ sudo reboot
>>
>> william@beaglebone:~$ sudo sh -c "echo 'WH-ADC' >
>> /sys/devices/platform/bone_capemgr/slots"
>> [   62.607962] bone_capemgr bone_capemgr: part_number 'WH-ADC', version
>> 'N/A'
>> [   62.614993] bone_capemgr bone_capemgr: slot #4: override
>> [   62.620338] bone_capemgr bone_capemgr: Using override eeprom data at
>> slot 4
>> [   62.627374] bone_capemgr bone_capemgr: slot #4: 'Override Board
>> Name,00A0,Override Manuf,WH-ADC'
>> [   62.649771] bone_capemgr bone_capemgr: slot #4: dtbo
>> 'WH-ADC-00A0.dtbo' loaded; overlay id #0
>>
>> So, something between these two versions, has changed, and has broken
>> what worked initially. Perhaps it could even be the adc alias in the main
>> board file ? I haven't looked yet . . .
>>
>>
>>
>>
>>
>> --
>> 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/7504f115-e242-4617-b956-d4549aeeb029%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/CALHSORriPMYZ6CVm4TBvrM4Fjw2CBgXK6Gdwt0PK_y3bKG%2BBzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Fundamental capemanager change between 4.1.x, and 4.4.x

[William Hermans]

Just for added measure, yes the UIO driver does work . .

william@beaglebone:~$ lsuio
uio0: name=tscadc, version=devicetree, events=0
map[0]: addr=0x44E0D000, size=4096


On Thu, Apr 21, 2016 at 9:51 PM, William Hermans  wrote:

> Ok, so the following does *NOT* work on a 4.4.x kernel, but does on a
> 4.1.x kernel.
>
> *Starting off with 4.4.x kernel*
>
> william@beaglebone:~$ cat ti/WH-ADC-00A0.dts
>
>
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> /* identification */
> part-number = "WH-ADC";
> version = "00A0";
>
>
> fragment@0 {
> target = <&tscadc>;
> __overlay__ {
> compatible = "uio";
> uio-alias = "adc";
> status = "okay";
> };
> };
> };
>
>
>
> william@beaglebone:~$ sudo touch /etc/modprobe.d/uio.conf
> william@beaglebone:~$ sudo nano /etc/modprobe.d/uio.conf
> # put in /etc/modprobe.d/uio.conf
> #
> # make driver match on  compatible = "uio";
> options uio_pdrv_genirq of_id=uio
>
> william@beaglebone:~$ ls /dev | grep uio /* Crickets . . .*/
>
> william@beaglebone:~$ sudo sh -c "echo ' WH-ADC' >
> /sys/devices/platform/bone_capemgr/slots"
> [ 3658.413635] bone_capemgr bone_capemgr: part_number ' WH-ADC', version
> 'N/A'
> [ 3658.420830] bone_capemgr bone_capemgr: slot #5: override
> [ 3658.426181] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 5
> [ 3658.433959] bone_capemgr bone_capemgr: slot #5: 'Override Board
> Name,00A0,Override Manuf, WH-ADC'
>
> *Changing to 4.1.x kernel*
>
> william@beaglebone:~$ sudo nano /boot/uEnv.txt
> uname_r=4.1.18-bone-rt-r19
> william@beaglebone:~$ sudo reboot
>
> william@beaglebone:~$ sudo sh -c "echo 'WH-ADC' >
> /sys/devices/platform/bone_capemgr/slots"
> [   62.607962] bone_capemgr bone_capemgr: part_number 'WH-ADC', version
> 'N/A'
> [   62.614993] bone_capemgr bone_capemgr: slot #4: override
> [   62.620338] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 4
> [   62.627374] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,WH-ADC'
> [   62.649771] bone_capemgr bone_capemgr: slot #4: dtbo
> 'WH-ADC-00A0.dtbo' loaded; overlay id #0
>
> So, something between these two versions, has changed, and has broken what
> worked initially. Perhaps it could even be the adc alias in the main board
> file ? I haven't looked yet . . .
>
>
>
>
>
> --
> 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/7504f115-e242-4617-b956-d4549aeeb029%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/CALHSORr965F4R8DN8h_n5%3DFoOcTUnxZ0R8xvuK7JNxYKpSXDGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Fundamental capemanager change between 4.1.x, and 4.4.x

[William Hermans]

Ok, so the following does *NOT* work on a 4.4.x kernel, but does on a 4.1.x 
kernel.

*Starting off with 4.4.x kernel*

william@beaglebone:~$ cat ti/WH-ADC-00A0.dts


/dts-v1/;
/plugin/;

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

/* identification */
part-number = "WH-ADC";
version = "00A0";


fragment@0 {
target = <&tscadc>;
__overlay__ {
compatible = "uio";
uio-alias = "adc";
status = "okay";
};
};
};



william@beaglebone:~$ sudo touch /etc/modprobe.d/uio.conf
william@beaglebone:~$ sudo nano /etc/modprobe.d/uio.conf
# put in /etc/modprobe.d/uio.conf
#
# make driver match on  compatible = "uio";
options uio_pdrv_genirq of_id=uio

william@beaglebone:~$ ls /dev | grep uio /* Crickets . . .*/

william@beaglebone:~$ sudo sh -c "echo ' WH-ADC' > 
/sys/devices/platform/bone_capemgr/slots"
[ 3658.413635] bone_capemgr bone_capemgr: part_number ' WH-ADC', version 
'N/A'
[ 3658.420830] bone_capemgr bone_capemgr: slot #5: override
[ 3658.426181] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 5
[ 3658.433959] bone_capemgr bone_capemgr: slot #5: 'Override Board 
Name,00A0,Override Manuf, WH-ADC'

*Changing to 4.1.x kernel*

william@beaglebone:~$ sudo nano /boot/uEnv.txt
uname_r=4.1.18-bone-rt-r19
william@beaglebone:~$ sudo reboot

william@beaglebone:~$ sudo sh -c "echo 'WH-ADC' > 
/sys/devices/platform/bone_capemgr/slots"
[   62.607962] bone_capemgr bone_capemgr: part_number 'WH-ADC', version 
'N/A'
[   62.614993] bone_capemgr bone_capemgr: slot #4: override
[   62.620338] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 4
[   62.627374] bone_capemgr bone_capemgr: slot #4: 'Override Board 
Name,00A0,Override Manuf,WH-ADC'
[   62.649771] bone_capemgr bone_capemgr: slot #4: dtbo 'WH-ADC-00A0.dtbo' 
loaded; overlay id #0

So, something between these two versions, has changed, and has broken what 
worked initially. Perhaps it could even be the adc alias in the main board 
file ? I haven't looked yet . . .





-- 
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/7504f115-e242-4617-b956-d4549aeeb029%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[William Hermans]

Also oddly enough, that method for loading an uio driver, at least the
demonstration uio driver for ADC is broken. Exact step instructions I've
created and tested personally no longer work. At least on my BBB with . . .

william@beaglebone:~$ uname -r
4.4.7-bone-rt-r9
william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01
william@beaglebone:~$ dtc -v
Version: DTC 1.4.1-g1e75ebc9


So it would seems that udev rule is no longer needed anyway . .



On Thu, Apr 21, 2016 at 9:08 PM, William Hermans  wrote:

> Anyway, if you have a device tree "compatible=uio" definition for any node
> in any device tree. It seems that udev rule will hammer the crap out of the
> system until the udev rule can actually do what it wants to.
>
> On Thu, Apr 21, 2016 at 9:05 PM, William Hermans 
> wrote:
>
>> @Robert,
>>
>> I think I found the answer to your question. From a text file based on
>> something another person on these forums was discussing with me . . .
>>
>> # put in /etc/modprobe.d/uio.conf
>> #
>> # make driver match on  compatible = "uio";
>> options uio_pdrv_genirq of_id=uio
>>
>>
>> # put in /etc/udev/rules.d/uio.rules
>> #
>> # create named symlink to locate the device easily
>> # (assumes your kernel is new enough to have of_node symlinks in sysfs)
>> SUBSYSTEM=="uio", SYMLINK+="uio/%s{device/of_node/uio-alias}"
>> #
>> # give some group access rights (adjust as needed)
>> SUBSYSTEM=="uio", GROUP="users", MODE="0660"
>>
>> So this was in relation to setting up a UIO ADC driver, and was pasted by
>> this same person as something for me to experiment with. Anyway this file I
>> have was created 11-19-2015, which is a pretty good indication of the date
>> when the discussion took place.
>>
>> On Thu, Apr 21, 2016 at 8:25 PM, Robert Nelson 
>> wrote:
>>
>>>
>>>
>>> On Thu, Apr 21, 2016 at 10:04 PM, Charles Steinkuehler <
>>> char...@steinkuehler.net> wrote:
>>>
 On 4/21/2016 9:43 PM, Charles Steinkuehler wrote:
 > On 4/21/2016 9:37 PM, Robert Nelson wrote:
 >>
 >> Does the uio_pruss still work if we just nuke that whole udev rule??
 >
 > Testing

>>>
>>> Thanks for testing Charles!
>>>
>>>

 Commenting the first line (with SYMLINK+=):
 ==
 No excessive CPU usage when loading a PRU device-tree overlay.
>>>
>>>

 Commenting both lines (same as not having a uio.rules file):
 ==
 No excessive CPU usage when loading a PRU device-tree overlay

 /dev/uio* permissions change from 0660 to 0600


 In both instances, I can use the PRU as expected (Machinekit loads and
 moves motors).

 I would recommend leaving the permissions rule (the second line) but
 comment out the first line (the SYMLINK+ line).  Honestly, IMHO there
 should be a udev rule that creates a device node that has "pru" or
 "pruss" in it somewhere, but since that's not how it was done
 previously...  ;-)

>>>
>>> I'll push the first line commenting change..
>>>
>>> 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/CAOCHtYgo--FX%3DLHYob143%2BPvEHw9mid9P3zskQm1qpbAsF_4Gw%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/CALHSORpsHDomuEpzs2AG3cYfNadvo7D9WGyo3e3aSruewf6zPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[William Hermans]

Anyway, if you have a device tree "compatible=uio" definition for any node
in any device tree. It seems that udev rule will hammer the crap out of the
system until the udev rule can actually do what it wants to.

On Thu, Apr 21, 2016 at 9:05 PM, William Hermans  wrote:

> @Robert,
>
> I think I found the answer to your question. From a text file based on
> something another person on these forums was discussing with me . . .
>
> # put in /etc/modprobe.d/uio.conf
> #
> # make driver match on  compatible = "uio";
> options uio_pdrv_genirq of_id=uio
>
>
> # put in /etc/udev/rules.d/uio.rules
> #
> # create named symlink to locate the device easily
> # (assumes your kernel is new enough to have of_node symlinks in sysfs)
> SUBSYSTEM=="uio", SYMLINK+="uio/%s{device/of_node/uio-alias}"
> #
> # give some group access rights (adjust as needed)
> SUBSYSTEM=="uio", GROUP="users", MODE="0660"
>
> So this was in relation to setting up a UIO ADC driver, and was pasted by
> this same person as something for me to experiment with. Anyway this file I
> have was created 11-19-2015, which is a pretty good indication of the date
> when the discussion took place.
>
> On Thu, Apr 21, 2016 at 8:25 PM, Robert Nelson 
> wrote:
>
>>
>>
>> On Thu, Apr 21, 2016 at 10:04 PM, Charles Steinkuehler <
>> char...@steinkuehler.net> wrote:
>>
>>> On 4/21/2016 9:43 PM, Charles Steinkuehler wrote:
>>> > On 4/21/2016 9:37 PM, Robert Nelson wrote:
>>> >>
>>> >> Does the uio_pruss still work if we just nuke that whole udev rule??
>>> >
>>> > Testing
>>>
>>
>> Thanks for testing Charles!
>>
>>
>>>
>>> Commenting the first line (with SYMLINK+=):
>>> ==
>>> No excessive CPU usage when loading a PRU device-tree overlay.
>>
>>
>>>
>>> Commenting both lines (same as not having a uio.rules file):
>>> ==
>>> No excessive CPU usage when loading a PRU device-tree overlay
>>>
>>> /dev/uio* permissions change from 0660 to 0600
>>>
>>>
>>> In both instances, I can use the PRU as expected (Machinekit loads and
>>> moves motors).
>>>
>>> I would recommend leaving the permissions rule (the second line) but
>>> comment out the first line (the SYMLINK+ line).  Honestly, IMHO there
>>> should be a udev rule that creates a device node that has "pru" or
>>> "pruss" in it somewhere, but since that's not how it was done
>>> previously...  ;-)
>>>
>>
>> I'll push the first line commenting change..
>>
>> 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/CAOCHtYgo--FX%3DLHYob143%2BPvEHw9mid9P3zskQm1qpbAsF_4Gw%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/CALHSORo2yNpR7dJ94gHyLW4f0-UoJ%3D4P6hFX%2BLyhwHMjakGWJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[William Hermans]

@Robert,

I think I found the answer to your question. From a text file based on
something another person on these forums was discussing with me . . .

# put in /etc/modprobe.d/uio.conf
#
# make driver match on  compatible = "uio";
options uio_pdrv_genirq of_id=uio


# put in /etc/udev/rules.d/uio.rules
#
# create named symlink to locate the device easily
# (assumes your kernel is new enough to have of_node symlinks in sysfs)
SUBSYSTEM=="uio", SYMLINK+="uio/%s{device/of_node/uio-alias}"
#
# give some group access rights (adjust as needed)
SUBSYSTEM=="uio", GROUP="users", MODE="0660"

So this was in relation to setting up a UIO ADC driver, and was pasted by
this same person as something for me to experiment with. Anyway this file I
have was created 11-19-2015, which is a pretty good indication of the date
when the discussion took place.

On Thu, Apr 21, 2016 at 8:25 PM, Robert Nelson 
wrote:

>
>
> On Thu, Apr 21, 2016 at 10:04 PM, Charles Steinkuehler <
> char...@steinkuehler.net> wrote:
>
>> On 4/21/2016 9:43 PM, Charles Steinkuehler wrote:
>> > On 4/21/2016 9:37 PM, Robert Nelson wrote:
>> >>
>> >> Does the uio_pruss still work if we just nuke that whole udev rule??
>> >
>> > Testing
>>
>
> Thanks for testing Charles!
>
>
>>
>> Commenting the first line (with SYMLINK+=):
>> ==
>> No excessive CPU usage when loading a PRU device-tree overlay.
>
>
>>
>> Commenting both lines (same as not having a uio.rules file):
>> ==
>> No excessive CPU usage when loading a PRU device-tree overlay
>>
>> /dev/uio* permissions change from 0660 to 0600
>>
>>
>> In both instances, I can use the PRU as expected (Machinekit loads and
>> moves motors).
>>
>> I would recommend leaving the permissions rule (the second line) but
>> comment out the first line (the SYMLINK+ line).  Honestly, IMHO there
>> should be a udev rule that creates a device node that has "pru" or
>> "pruss" in it somewhere, but since that's not how it was done
>> previously...  ;-)
>>
>
> I'll push the first line commenting change..
>
> 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/CAOCHtYgo--FX%3DLHYob143%2BPvEHw9mid9P3zskQm1qpbAsF_4Gw%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/CALHSORrGro3w38s9tVbny67be4kUeLF8u9YXnhwkDwfn%2B%3DEq9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[Robert Nelson]

On Thu, Apr 21, 2016 at 10:04 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 4/21/2016 9:43 PM, Charles Steinkuehler wrote:
> > On 4/21/2016 9:37 PM, Robert Nelson wrote:
> >>
> >> Does the uio_pruss still work if we just nuke that whole udev rule??
> >
> > Testing
>

Thanks for testing Charles!


>
> Commenting the first line (with SYMLINK+=):
> ==
> No excessive CPU usage when loading a PRU device-tree overlay.


>
> Commenting both lines (same as not having a uio.rules file):
> ==
> No excessive CPU usage when loading a PRU device-tree overlay
>
> /dev/uio* permissions change from 0660 to 0600
>
>
> In both instances, I can use the PRU as expected (Machinekit loads and
> moves motors).
>
> I would recommend leaving the permissions rule (the second line) but
> comment out the first line (the SYMLINK+ line).  Honestly, IMHO there
> should be a udev rule that creates a device node that has "pru" or
> "pruss" in it somewhere, but since that's not how it was done
> previously...  ;-)
>

I'll push the first line commenting change..

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

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[Charles Steinkuehler]

On 4/21/2016 9:43 PM, Charles Steinkuehler wrote:
> On 4/21/2016 9:37 PM, Robert Nelson wrote:
>>
>> Does the uio_pruss still work if we just nuke that whole udev rule??
> 
> Testing

Commenting the first line (with SYMLINK+=):
==
No excessive CPU usage when loading a PRU device-tree overlay.


Commenting both lines (same as not having a uio.rules file):
==
No excessive CPU usage when loading a PRU device-tree overlay

/dev/uio* permissions change from 0660 to 0600


In both instances, I can use the PRU as expected (Machinekit loads and
moves motors).

I would recommend leaving the permissions rule (the second line) but
comment out the first line (the SYMLINK+ line).  Honestly, IMHO there
should be a udev rule that creates a device node that has "pru" or
"pruss" in it somewhere, but since that's not how it was done
previously...  ;-)

-- 
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/571994BB.2090304%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[William Hermans]

Robert, Charles,

One thing that confused me, was why does the uio_pruss driver add 8 mmap()
file objects in that /dev/uio directory structure. They all point to the
same address in memory it seems too.


Also according to older exact step how-to's from aroudn 2013-2014, this hs
omehow changed from a single file object, to 8. Perhaps that udev line is
the cause ?

On Thu, Apr 21, 2016 at 7:43 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 4/21/2016 9:37 PM, Robert Nelson wrote:
> >
> > Does the uio_pruss still work if we just nuke that whole udev rule??
>
> Testing
>
> --
> 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/57198FD7.1040804%40steinkuehler.net
> .
> 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/CALHSORpTQwt%2BHR7B42cZz0qk%3D566D7eHbQY8gXY6r9jroRmzfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[Charles Steinkuehler]

On 4/21/2016 9:37 PM, Robert Nelson wrote:
> 
> Does the uio_pruss still work if we just nuke that whole udev rule??

Testing

-- 
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/57198FD7.1040804%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[Robert Nelson]

On Thu, Apr 21, 2016 at 9:01 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 4/21/2016 7:41 PM, Charles Steinkuehler wrote:
> > On 4/21/2016 7:32 PM, Robert Nelson wrote:
> >> On Thu, Apr 21, 2016 at 7:25 PM, Charles Steinkuehler <
> char...@steinkuehler.net
> >> > wrote:
> >>
> >> and of course, i never added who pinged me on this, when i pushed the
> change...
> >>
> >>
> https://github.com/RobertCNelson/omap-image-builder/commit/47f982cf2896664dacd21126cf4381b078b94d15
> >
> > Well things are _mostly_ working.  The /dev/uio[0-7] entries are
> > created, they apparently just don't get symlinked to wherever it is
> > the first line in the uio.rules file is trying to put them.
> >
> > Any ideas what this was all about?
> >
> > Is it OK to just comment out the SYMLINK line?
>
> After further testing, if you create a /dev/uio directory before
> trying to load a uio driver (like the PRU driver), everything works
> fine.  Interestingly, there are *NO* symlinks actually generated in
> the /dev/uio directory, but the simple fact that it exists seems to be
> enough to keep the systemd-udevd processes from chewing up tons of CPU
> until they get killed.
>
> So the solution seems to be one of:
>
> * Create a /dev/uio directory
>
> * Remove the SYMLINK line from /etc/udev/uio.rules
>
> I'm not enough of a udev guru to know which is the better option, but
> removing or commenting the SYMLINK line in uio.rules seems like the
> better choice, since there aren't any symlinks generated anyway.
>

Does the uio_pruss still work if we just nuke that whole udev rule??

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

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[William Hermans]

>
> *After further testing, if you create a /dev/uio directory before*
> * trying to load a uio driver (like the PRU driver), everything works*
> * fine.  Interestingly, there are *NO* symlinks actually generated in*
> * the /dev/uio directory, but the simple fact that it exists seems to be*
> * enough to keep the systemd-udevd processes from chewing up tons of CPU*
> * until they get killed.*
>
> * So the solution seems to be one of:*
>
> * * Create a /dev/uio directory*
>
> * * Remove the SYMLINK line from /etc/udev/uio.rules*
>
> * I'm not enough of a udev guru to know which is the better option, but*
> * removing or commenting the SYMLINK line in uio.rules seems like the*
> * better choice, since there aren't any symlinks generated anyway.*
>

I'm not an expert Charles, but I think the symlink should be removed from
the udev rules file, and when various drivers that require uio are
installed via *however* the "vendor" needs to include their own *.rules
file. That's how it's done already in many cases.

As creating a directory structure in the /dev/ directory tree probably is
not a good idea if it never gets used, or even just isn't installed.
Because it could be a potential cause of confusion.


On Thu, Apr 21, 2016 at 7:01 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 4/21/2016 7:41 PM, Charles Steinkuehler wrote:
> > On 4/21/2016 7:32 PM, Robert Nelson wrote:
> >> On Thu, Apr 21, 2016 at 7:25 PM, Charles Steinkuehler <
> char...@steinkuehler.net
> >> > wrote:
> >>
> >> and of course, i never added who pinged me on this, when i pushed the
> change...
> >>
> >>
> https://github.com/RobertCNelson/omap-image-builder/commit/47f982cf2896664dacd21126cf4381b078b94d15
> >
> > Well things are _mostly_ working.  The /dev/uio[0-7] entries are
> > created, they apparently just don't get symlinked to wherever it is
> > the first line in the uio.rules file is trying to put them.
> >
> > Any ideas what this was all about?
> >
> > Is it OK to just comment out the SYMLINK line?
>
> After further testing, if you create a /dev/uio directory before
> trying to load a uio driver (like the PRU driver), everything works
> fine.  Interestingly, there are *NO* symlinks actually generated in
> the /dev/uio directory, but the simple fact that it exists seems to be
> enough to keep the systemd-udevd processes from chewing up tons of CPU
> until they get killed.
>
> So the solution seems to be one of:
>
> * Create a /dev/uio directory
>
> * Remove the SYMLINK line from /etc/udev/uio.rules
>
> I'm not enough of a udev guru to know which is the better option, but
> removing or commenting the SYMLINK line in uio.rules seems like the
> better choice, since there aren't any symlinks generated anyway.
>
> --
> 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/57198616.6050505%40steinkuehler.net
> .
> 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/CALHSORpvX3CzLTTiw73yQMaFRq%2Ben80Tsw%3DRxznqpcOrNThGHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[Charles Steinkuehler]

On 4/21/2016 7:41 PM, Charles Steinkuehler wrote:
> On 4/21/2016 7:32 PM, Robert Nelson wrote:
>> On Thu, Apr 21, 2016 at 7:25 PM, Charles Steinkuehler 
>> > > wrote:
>>
>> and of course, i never added who pinged me on this, when i pushed the 
>> change...
>>
>> https://github.com/RobertCNelson/omap-image-builder/commit/47f982cf2896664dacd21126cf4381b078b94d15
> 
> Well things are _mostly_ working.  The /dev/uio[0-7] entries are
> created, they apparently just don't get symlinked to wherever it is
> the first line in the uio.rules file is trying to put them.
> 
> Any ideas what this was all about?
> 
> Is it OK to just comment out the SYMLINK line?

After further testing, if you create a /dev/uio directory before
trying to load a uio driver (like the PRU driver), everything works
fine.  Interestingly, there are *NO* symlinks actually generated in
the /dev/uio directory, but the simple fact that it exists seems to be
enough to keep the systemd-udevd processes from chewing up tons of CPU
until they get killed.

So the solution seems to be one of:

* Create a /dev/uio directory

* Remove the SYMLINK line from /etc/udev/uio.rules

I'm not enough of a udev guru to know which is the better option, but
removing or commenting the SYMLINK line in uio.rules seems like the
better choice, since there aren't any symlinks generated anyway.

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

Re: [beagleboard] uio_pruss on Mainline Linux

[William Hermans]

>
> *  That reminds me of the 68000 CPU manuals back in the day (when*
> * you actually had dead-tree printed book data-sheets).  The first*
> * edition was *HUGE* (about 2 inches thick), but after several years had*
> * gone by, the manual was only about 1/2 an inch thick.  They had*
> * removed all the basic information everyone was supposed to "just*
> * know", but without which you would be totally lost.*
>
> * I guess it's called "progress".  :)*
>
> * Now I just save each and every datasheet I ever download from the*
> * internet.  Usually, the latest version is what I need, but sometimes*
> * there are details in the older versions that got removed in a*
> * subsequent update.*
>

Soundsl iek you and my buddy would get along just dandy. heh, he must have
several gigs of pdf's ( yes . . datasheets ) that migrate from new system
to new system when he upgrades ;)

He's also a mame / retro arcade board collector, lots of 68000's out there
;)

On Thu, Apr 21, 2016 at 5:46 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 4/21/2016 7:37 PM, William Hermans wrote:
> > I had someone on this group tell me not long ago that I must be joking
> when I
> > tried to explain I was note sure how something worked with remoteproc on
> the
> > PRU's. But see that the problem when you're dealing with someone whose
> known the
> > secrete handshake for a long enough period of time that they forget the
> rest of
> > the world doesn't know what's going on.
>
>   That reminds me of the 68000 CPU manuals back in the day (when
> you actually had dead-tree printed book data-sheets).  The first
> edition was *HUGE* (about 2 inches thick), but after several years had
> gone by, the manual was only about 1/2 an inch thick.  They had
> removed all the basic information everyone was supposed to "just
> know", but without which you would be totally lost.
>
> I guess it's called "progress".  :)
>
> Now I just save each and every datasheet I ever download from the
> internet.  Usually, the latest version is what I need, but sometimes
> there are details in the older versions that got removed in a
> subsequent update.
>
> --
> 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/57197482.10500%40steinkuehler.net
> .
> 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/CALHSORq7fFPWEeBTTeGJ9-Fb18droN7uiUKxgX5G%3DXRQcvComg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] uio_pruss on Mainline Linux

[John Syne]

But this was done a while ago when the added support for ethernet. I’m not 
aware of any other changes. 

Regards,
John




> On Apr 21, 2016, at 5:21 PM, Robert Nelson  wrote:
> 
> 
> 
> On Thu, Apr 21, 2016 at 7:09 PM, Jordan Yelloz  > wrote:
> Thanks, that appears to be a pretty small patch, I'll try it out.
> I would have no problem using the remoteproc_pruss if it was in the official 
> kernel but I can't see any as of 4.6-rc4.
> 
> remoteproc_pruss is getting "redesigned" again... ;(
> 
> I'm tempted to say, let's just clean it up and push it.
> 
> If someone complains, uio_pruss has been in mainline for awhile, and 
> remoteproc_pruss has gone no where. ;)
> 
> 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/CAOCHtYggjgGzF-wgU5hac8om7XwBoH6DNZg%3DGqanHoG7j0Ji%3DQ%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/CCD3E8F7-B3EB-475A-91E0-E2E5CD34C092%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] uio_pruss on Mainline Linux

[Charles Steinkuehler]

On 4/21/2016 7:37 PM, William Hermans wrote:
> I had someone on this group tell me not long ago that I must be joking when I 
> tried to explain I was note sure how something worked with remoteproc on the 
> PRU's. But see that the problem when you're dealing with someone whose known 
> the 
> secrete handshake for a long enough period of time that they forget the rest 
> of 
> the world doesn't know what's going on.

  That reminds me of the 68000 CPU manuals back in the day (when
you actually had dead-tree printed book data-sheets).  The first
edition was *HUGE* (about 2 inches thick), but after several years had
gone by, the manual was only about 1/2 an inch thick.  They had
removed all the basic information everyone was supposed to "just
know", but without which you would be totally lost.

I guess it's called "progress".  :)

Now I just save each and every datasheet I ever download from the
internet.  Usually, the latest version is what I need, but sometimes
there are details in the older versions that got removed in a
subsequent update.

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

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[Charles Steinkuehler]

On 4/21/2016 7:32 PM, Robert Nelson wrote:
> On Thu, Apr 21, 2016 at 7:25 PM, Charles Steinkuehler 
>  > wrote:
> 
> OK, this doesn't appear to be a PRU issue, it's a fundamental problem
> with udev.  The systemd-udevd process that are chewing up CPU cycles
> are endlessly trying to create a symlink due to the contents of
> /etc/udev/rules.d/uio.rules, which contains:
> 
> SUBSYSTEM=="uio", SYMLINK+="uio/%s{device/of_node/uio-alias}"
> SUBSYSTEM=="uio", GROUP="users", MODE="0660"
> 
> When you strace one of the 'stuck' systemd-udevd processes, you get an
> endless (until the process is killed) repeating stream of:
> 
>  > mkdir("/dev", 0755) = -1 EEXIST (File exists)
>  > symlink("../uio1", "/dev/uio/") = -1 ENOENT (No such file or
> directory)
>  > stat64("/dev/uio", 0xbeffb430)  = -1 ENOENT (No such file or
> directory)
>  > mkdir("/dev", 0755) = -1 EEXIST (File exists)
>  > symlink("../uio1", "/dev/uio/") = -1 ENOENT (No such file or
> directory)
>  > stat64("/dev/uio", 0xbeffb430)  = -1 ENOENT (No such file or
> directory)
>  > ...
> 
> The symlink fails because there is no /dev/uio directory, which the
> systemd-udevd process seems to think is supposed to exist.
> 
> Any uio and/or udev gurus know what's going on?
> 
> 
> and of course, i never added who pinged me on this, when i pushed the 
> change...
> 
> https://github.com/RobertCNelson/omap-image-builder/commit/47f982cf2896664dacd21126cf4381b078b94d15

Well things are _mostly_ working.  The /dev/uio[0-7] entries are
created, they apparently just don't get symlinked to wherever it is
the first line in the uio.rules file is trying to put them.

Any ideas what this was all about?

Is it OK to just comment out the SYMLINK line?

-- 
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/5719733F.8010809%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] uio_pruss on Mainline Linux

[William Hermans]

>
> *Thanks, that appears to be a pretty small patch, I'll try it out.*
> *I would have no problem using the remoteproc_pruss if it was in the
> official kernel but I can't see any as of 4.6-rc4.*
>

The main problem I see with remoteproc is that it is not as well documented
as uio_pruss. Many aspects of how to use, and setup remoteproc are not very
clear. For instance, you have these magic "map" files that I have been able
to find zero documentation on. Which is in relation to configuration for
PRUs as far as I can tell. .bss, data segments, etc, but it's not
documented at all. So we're left to assume we know what we're doing. I
personally, do not like to operate like that at all.

I had someone on this group tell me not long ago that I must be joking when
I tried to explain I was note sure how something worked with remoteproc on
the PRU's. But see that the problem when you're dealing with someone whose
known the secrete handshake for a long enough period of time that they
forget the rest of the world doesn't know what's going on.

Anyway, uio_pruss has been around long enough to have worked well on the
white, and the driver code is really short and easy to read through. Not to
mention that UIO is just really cool technology to begin with.

remoteproc is really cool technology too as far as I'm concerned, but where
it really belongs in my personal opinion, is multi core application
processors. So you could for instance run a dual core processor as a single
core running Linux, and a single core running bare metal. *THAT* is an
awesome concept. But reinventing drivers for a high speed peripheral that
already has reallt good drivers is . . . well . . ." don't fix what ain't
broke . . "

On Thu, Apr 21, 2016 at 5:09 PM, Jordan Yelloz 
wrote:

> Thanks, that appears to be a pretty small patch, I'll try it out.
> I would have no problem using the remoteproc_pruss if it was in the
> official kernel but I can't see any as of 4.6-rc4.
>
> --
> 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/036b8c05-6fd1-40f5-8bc9-cf554541dd8d%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/CALHSORqae%3DfVLP214LLz4az6RfEk2KHjJcDWa30fD%3DCTvYOOMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[Robert Nelson]

On Thu, Apr 21, 2016 at 7:25 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 4/10/2016 3:36 PM, Charles Steinkuehler wrote:
> > On 4/10/2016 3:17 PM, Charles Steinkuehler wrote:
> >> On 4/10/2016 11:13 AM, Charles Steinkuehler wrote:
> >>> I am experimenting with getting Machinekit running on Debian Jessie,
> >>> and have run into an issue with loading capes.
> >>>
> >>> After I manually load a cape:
> >>>
> >>> $ SLOTS=/sys/devices/bone_capemgr.*/slots
> >>> $ sudo -A su -c "echo cape-bebopr-brdg:R2 > $SLOTS"
> >>>
> >>> ...CPU usage maxes out and I have eight systemd-udevd tasks running
> >>> that are each taking a good chunk of the CPU.  These typically go away
> >>> after apx. 17 seconds of CPU time (each), or about 2-1/2 minutes, but
> >>> I'm wondering what in the world is going on.
> >>>
> >>> Is this a known issue?  Any ideas how to tell what the systemd-udevd
> >>> processes are doing?
> >>>
> >>> The kernel is 3.8.13-xenomai-r78, which works fine under Wheezy.
> >>
> >> I get the same results with a "stock" Debian Jessie image (
> >>
> >> debian@beaglebone:~$ cat /etc/dogtag
> >> BeagleBoard.org Debian Image 2016-03-27
> >>
> >> ...using the 3.8.13-bone79 kernel.  The 4.1.18-ti-r55 kernel provide
> >> with the Jessie image has a cape manager (although the slots file is
> >> in a different location), but trying to load the cape-bebopr-brdg:R2
> >> cape fails.
> >>
> >> Any hints as to how to debug would be very welcome!
>
> OK, this doesn't appear to be a PRU issue, it's a fundamental problem
> with udev.  The systemd-udevd process that are chewing up CPU cycles
> are endlessly trying to create a symlink due to the contents of
> /etc/udev/rules.d/uio.rules, which contains:
>
> SUBSYSTEM=="uio", SYMLINK+="uio/%s{device/of_node/uio-alias}"
> SUBSYSTEM=="uio", GROUP="users", MODE="0660"
>
> When you strace one of the 'stuck' systemd-udevd processes, you get an
> endless (until the process is killed) repeating stream of:
>
> > mkdir("/dev", 0755) = -1 EEXIST (File exists)
> > symlink("../uio1", "/dev/uio/") = -1 ENOENT (No such file or
> directory)
> > stat64("/dev/uio", 0xbeffb430)  = -1 ENOENT (No such file or
> directory)
> > mkdir("/dev", 0755) = -1 EEXIST (File exists)
> > symlink("../uio1", "/dev/uio/") = -1 ENOENT (No such file or
> directory)
> > stat64("/dev/uio", 0xbeffb430)  = -1 ENOENT (No such file or
> directory)
> > ...
>
> The symlink fails because there is no /dev/uio directory, which the
> systemd-udevd process seems to think is supposed to exist.
>
> Any uio and/or udev gurus know what's going on?
>

and of course, i never added who pinged me on this, when i pushed the
change...

https://github.com/RobertCNelson/omap-image-builder/commit/47f982cf2896664dacd21126cf4381b078b94d15

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/CAOCHtYhaA%2B9OSiyRu9XE%2Bt%3DaO2_4e8Pguf%3Dsx5-LeULY4a8P7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] High CPU usage after loading a cape on Jessie

[Charles Steinkuehler]

On 4/10/2016 3:36 PM, Charles Steinkuehler wrote:
> On 4/10/2016 3:17 PM, Charles Steinkuehler wrote:
>> On 4/10/2016 11:13 AM, Charles Steinkuehler wrote:
>>> I am experimenting with getting Machinekit running on Debian Jessie,
>>> and have run into an issue with loading capes.
>>>
>>> After I manually load a cape:
>>>
>>> $ SLOTS=/sys/devices/bone_capemgr.*/slots
>>> $ sudo -A su -c "echo cape-bebopr-brdg:R2 > $SLOTS"
>>>
>>> ...CPU usage maxes out and I have eight systemd-udevd tasks running
>>> that are each taking a good chunk of the CPU.  These typically go away
>>> after apx. 17 seconds of CPU time (each), or about 2-1/2 minutes, but
>>> I'm wondering what in the world is going on.
>>>
>>> Is this a known issue?  Any ideas how to tell what the systemd-udevd
>>> processes are doing?
>>>
>>> The kernel is 3.8.13-xenomai-r78, which works fine under Wheezy.
>>
>> I get the same results with a "stock" Debian Jessie image (
>>
>> debian@beaglebone:~$ cat /etc/dogtag
>> BeagleBoard.org Debian Image 2016-03-27
>>
>> ...using the 3.8.13-bone79 kernel.  The 4.1.18-ti-r55 kernel provide
>> with the Jessie image has a cape manager (although the slots file is
>> in a different location), but trying to load the cape-bebopr-brdg:R2
>> cape fails.
>>
>> Any hints as to how to debug would be very welcome!

OK, this doesn't appear to be a PRU issue, it's a fundamental problem
with udev.  The systemd-udevd process that are chewing up CPU cycles
are endlessly trying to create a symlink due to the contents of
/etc/udev/rules.d/uio.rules, which contains:

SUBSYSTEM=="uio", SYMLINK+="uio/%s{device/of_node/uio-alias}"
SUBSYSTEM=="uio", GROUP="users", MODE="0660"

When you strace one of the 'stuck' systemd-udevd processes, you get an
endless (until the process is killed) repeating stream of:

> mkdir("/dev", 0755) = -1 EEXIST (File exists)
> symlink("../uio1", "/dev/uio/") = -1 ENOENT (No such file or 
> directory)
> stat64("/dev/uio", 0xbeffb430)  = -1 ENOENT (No such file or 
> directory)
> mkdir("/dev", 0755) = -1 EEXIST (File exists)
> symlink("../uio1", "/dev/uio/") = -1 ENOENT (No such file or 
> directory)
> stat64("/dev/uio", 0xbeffb430)  = -1 ENOENT (No such file or 
> directory)
> ...

The symlink fails because there is no /dev/uio directory, which the
systemd-udevd process seems to think is supposed to exist.

Any uio and/or udev gurus know what's going on?

-- 
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/57196F87.3060309%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] uio_pruss on Mainline Linux

[Robert Nelson]

On Thu, Apr 21, 2016 at 7:09 PM, Jordan Yelloz 
wrote:

> Thanks, that appears to be a pretty small patch, I'll try it out.
> I would have no problem using the remoteproc_pruss if it was in the
> official kernel but I can't see any as of 4.6-rc4.
>

remoteproc_pruss is getting "redesigned" again... ;(

I'm tempted to say, let's just clean it up and push it.

If someone complains, uio_pruss has been in mainline for awhile, and
remoteproc_pruss has gone no where. ;)

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

[beagleboard] Re: Extracting eMMC contents using FAT formatted card

[swilliamwill]

I had this same problem. I hadn't set the SD disk partition to "ACTIVE". 
Once I did that the LEDs came on.

On Monday, March 9, 2015 at 9:58:15 AM UTC-7, Felipe ordoñez wrote:
>
> Hi, 
>
> I have tried to save my information with this procedure,  but when the BBB 
> start  (Power led ON),  with the S2 pushed,  The USR leds are not Blinked 
> (OFF), I pushed for several seconds and minutes, but they do not turn ON,   
>  after 15 or 20 min. nothing happen inseide the uSD,  no data are save?
>
> Could someone help me?,   can't have my data save in order to reflashed 
> the BBB
>
>
>
>
>
> El jueves, 26 de septiembre de 2013, 12:16:54 (UTC-5), Jason Kridner 
> escribió:
>>
>> There are lots of ways to extract the contents of the eMMC to save off 
>> and reuse. I'm proposing a method using Buildroot and an initramfs such 
>> that you can simply drop a few files from a .zip onto a normal, 
>> FAT-formatted SD card to perform the extraction. There are several things 
>> really handy here, such as the ability to edit autorun.sh to be whatever 
>> script you want to run on your board at boot. In the archive, I only have 
>> the necessary autorun.sh for *saving* your eMMC content. The flip-side is 
>> provided here in the text such that you need to go through a couple of 
>> steps before you trash your eMMC.
>>
>> The steps for saving off your eMMC contents to a file:
>> * Get a 4GB or larger uSD card that is FAT formatted.
>> * Download https://s3.amazonaws.com/beagle/beagleboneblack-save-emmc.zip 
>> and extract the contents onto your uSD card.
>> * Eject uSD card from your computer, insert into powered-off BeagleBone 
>> Black and apply power to your board.
>> * You'll notice USR0 (the LED closest to the S1 button in the corner) 
>> will (after about 20 seconds) start to blink steadily, rather than the 
>> double-pulse "heartbeat" pattern that is typical when your BeagleBone Black 
>> is running the typical Linux kernel configuration.
>> * It'll run for a bit under 10 minutes and then USR0 will stay ON steady. 
>> That's your cue to remove power, remove the uSD card and put it back into 
>> your computer.
>> * You should see a file called BeagleBoneBlack-eMMC-image-X.img, 
>> where X is a set of random numbers. Save off this file to use for 
>> restoring your image later.
>>
>> Because the date won't be set on your board, you might want to adjust the 
>> date on the file to remember when you made it. Delete the file if you want 
>> to make room for a new backup image. For storage on your computer, these 
>> images will typically compress very well, so use your favorite compression 
>> tool.
>>
>> To restore the file, make sure there is a valid 
>> BeagleBoneBlack-eMMC-image-.img file on the uSD card and edit 
>> autorun.sh with your favorite text editor to contain the following:
>> #!/bin/sh
>> echo timer > /sys/class/leds/beaglebone\:green\:usr0/trigger 
>> dd if=/mnt/BeagleBoneBlack-eMMC-image-X.img of=/dev/mmcblk1 bs=10M
>> sync
>> echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger
>>
>> *NOTE*: Be certain to replace the 'X' above with the proper name of 
>> your image file.
>>
>> This image was built using Buildroot. The sources are at 
>> https://github.com/jadonk/buildroot with tag save-emmc-0.0.1. Download 
>> via https://github.com/jadonk/buildroot/releases/tag/save-emmc-0.0.1 or 
>> clone the git repo. It is a small fork from git://
>> git.buildroot.net/buildroot tag e9f6011617528646768e69203e85fe64364b7efd.
>>
>> To build, 'make beagleboneblack_defconfig; make; ./mkuimage.sh'.  Output 
>> files (am335x-boneblack.dtb, MLO, u-boot.img and uImage) will be in the 
>> output/images subdirectory. The following files were created manually.
>>
>> uEnv.txt:
>> bootpart=0:1
>> bootdir=
>> fdtaddr=0x81FF
>> optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>> uenvcmd=load mmc 0 ${loadaddr} uImage;run loadfdt;setenv bootargs 
>> console=${console} ${optargs};bootm ${loadaddr} - ${fdtaddr}
>>
>> autorun.sh:
>> #!/bin/sh
>> echo timer > /sys/class/leds/beaglebone\:green\:usr0/trigger 
>> dd if=/dev/mmcblk1 of=/mnt/BeagleBoneBlack-eMMC-image-$RANDOM.img bs=10M 
>> sync
>> echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger
>>
>> The kernel is based on 
>> https://github.com/beagleboard/kernel/commit/9fdb452245a58158a4bea787cdc663c17681bcfe,
>>  
>> but I applied the patches, added firmware and uploaded it to 
>> https://github.com/beagleboard/linux/commit/ddd36e546e53d3c493075bbebd6188ee843208f9
>>  
>> to pull down in the Buildroot makefile. The link to the source for the 
>> firmware is in the commit.
>>
>> I've applied to join the Buildroot mailing list to send these patches 
>> upstream. The power management firmware is not yet loading properly, but 
>> that is something I can look into.
>>
>> Happy hacking!
>>
>

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

Re: [beagleboard] uio_pruss on Mainline Linux

[Jordan Yelloz]

Thanks, that appears to be a pretty small patch, I'll try it out.
I would have no problem using the remoteproc_pruss if it was in the 
official kernel but I can't see any as of 4.6-rc4.

-- 
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/036b8c05-6fd1-40f5-8bc9-cf554541dd8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] uio_pruss on Mainline Linux

[Robert Nelson]

On Thu, Apr 21, 2016 at 6:41 PM, Jordan Yelloz 
wrote:

> Hi, I've been wondering for a while, since there is a driver in mainline
> Linux called uio_pruss, what can we actually do with it? Does it work with
> the beaglebone black? I have built Linux 4.5.2 with this support enabled
> (i've tried a few other versions too) but there's no information on what
> needs to be done for somebody to enable this module to actually register
> the PRU in Linux. I assume it works in ti-linux but I would rather not use
> that for my personal use case since the mainline kernel is good enough for
> all my other purposes.
>

Here is the patch we've been carrying..

https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.5/patches/pru_uio

All the TI/Kernel people want people to use remoteproc_pruss...

While everyone uses uio_pruss. ;)

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

[beagleboard] uio_pruss on Mainline Linux

[Jordan Yelloz]

Hi, I've been wondering for a while, since there is a driver in mainline 
Linux called uio_pruss, what can we actually do with it? Does it work with 
the beaglebone black? I have built Linux 4.5.2 with this support enabled 
(i've tried a few other versions too) but there's no information on what 
needs to be done for somebody to enable this module to actually register 
the PRU in Linux. I assume it works in ti-linux but I would rather not use 
that for my personal use case since the mainline kernel is good enough for 
all my other purposes.

Thanks.

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

Re: [beagleboard] BeagleBone Black RTC Wake Alarms

[William Hermans]

drivers/soc/ti/wkup_m3_ipc.c Also from memory has nothing to do with the
rtc wakeup stuff. That actually is for  the PRU's or possibly other
peripherals sharing the L3 interconnect fabric on the am335x processor.

Sorry, I missed that the first time I read your post.

On Thu, Apr 21, 2016 at 3:26 PM, William Hermans  wrote:

> I can tell you that using kernel 4.1.x
> https://www.linux.com/learn/wake-linux-rtc-alarm-clock works. I'm not
> sure that rtc wake timer is related to the one you're asking. However, I
> can tell you that once the main am335x processor loses power, or the
> ability to act from being in sleep mode, the RTC on the processor die will
> no longer function correctly. There has been some discussion on these
> forums about this in the past, and I do believe there was actually an
> errata on this as well.
>
> On Thu, Apr 21, 2016 at 9:52 AM,  wrote:
>
>> I am trying to use power management (sleep mode) in a way that is similar
>> to how Android does it with timerfd and epoll. I want to enable autosleep
>> and use RTC wake timers (created using timerfd) that wake the system back
>> up and prevent sleep mode (using epoll mechanism) until the timer event is
>> handled and all wakelocks have been released again.
>>
>> When I try using this approach, the wake timer created using timerfd does
>> not wake the system (however, the rtcwake command does work). I'm not sure
>> if this is supported by the BeagleBone kernel or not. I found the following
>> code references from Linux 3.12 code, but appears to be replaced with dts
>> and drivers/soc/ti/wkup_m3_ipc.c in Linux 3.14. Could there be something
>> missing from arch/arm/boot/dts/am33xx.dtsi that would enable what I need?
>>
>>
>> Reference from 3.12 source:
>>
>> struct wkup_m3_wakeup_src wakeups[] = {
>> {.irq_nr = 35,  .src = "USB0_PHY"},
>> {.irq_nr = 36,  .src = "USB1_PHY"},
>> {.irq_nr = 40,  .src = "I2C0"},
>> {.irq_nr = 41,  .src = "RTC Timer"},
>> {.irq_nr = 42,  .src = "RTC Alarm"},
>> {.irq_nr = 43,  .src = "Timer0"},
>> {.irq_nr = 44,  .src = "Timer1"},
>> {.irq_nr = 45,  .src = "UART"},
>> {.irq_nr = 46,  .src = "GPIO0"},
>> {.irq_nr = 48,  .src = "MPU_WAKE"},
>> {.irq_nr = 49,  .src = "WDT0"},
>> {.irq_nr = 50,  .src = "WDT1"},
>> {.irq_nr = 51,  .src = "ADC_TSC"},
>> {.irq_nr = 0,   .src = "Unknown"},
>> };
>>
>>
>> Environment
>> -
>> 3.14.55-ti-r78 kernel
>> Debian 8.3 filesystem
>> rtcwake command works successfully
>>
>> --
>> 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/23d3c790-6165-4920-a85f-47ae17c0cbb8%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/CALHSORqbtNU%2B6mhs324AFRYLPHQpqHO8H6CKHDvqpWgHNrpC-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Spurious power button press with new Debian

[William Hermans]

Sorry, and actually there should be no white spaces in that period. So .  .
.

cmdline=kernel.nmi_watchdog=0

On Thu, Apr 21, 2016 at 3:42 PM, William Hermans  wrote:

> *With the newest Debian distro, whenever I do that, I get a message that
>> the power button has been pressed, and the BBB simply shuts down after
>> that. *
>>
>
>
>> Any ideas on what might have changed in the OS for this to happen?
>
>
> Code I could not say what exactly has changed, but I can say the code in
> the context of the button press NMI *has* definitely changed since.
>
>  I can give you something to experiment with that may actually fix that
> issue for you.
>
> william@beaglebone:~$ sudo sysctl -a | grep nmi
> kernel.nmi_watchdog = 0
>
> If kernel.nmi_watchdog = comes back equal to 1 for you. Then simply
> changing this to zero ( 0 ) may solve the problem. so changing the cmdline=
> line in /boot/uEnv.txt to. . .
>
> cmdline=kernel.nmi_watchdog = 0
>
> Do keep in mind that this is supposed to be an x86 / x86-64 cmd line
> option only, so may not work. But the sysfs entries are there, so I'm
> thinking it should work . . .
>
> On Thu, Apr 21, 2016 at 9:55 AM,  wrote:
>
>> Hello guys,
>> I have a custom carrier board powering my Beaglebone Black through the 5V
>> supply pins on P9 (pins 5+6, I believe).
>>
>> Because I'm having issues getting my working legacy Angstrom distribution
>> image cloned onto new boards that have Micron flash instead of Kingston, I
>> decided to give a newer Debian a quick try.
>> I have a 3.3V power regulator with an enable input on the board, so the
>> BBB needs to assert a particular GPIO high to enable that power rail.
>> With the newest Debian distro, whenever I do that, I get a message that
>> the power button has been pressed, and the BBB simply shuts down after that.
>>
>> My 5V regulator can supply up to 5A, and this switchable 3.3V rail
>> doesn't even really have any load on it yet until I install the rest of the
>> hardware, so I don't believe it should have created any substantial drop in
>> the 5V power.
>>
>> I can do the same operation on the same (older) BBB with Angstrom
>> installed and I do not have this problem.
>>
>> Any ideas on what might have changed in the OS for this to happen?
>> I may go back down the road of figuring out how to clone my Angstrom
>> build over to the new boards, but still kind of curious why this might have
>> happened.
>>
>> --
>> 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/37ab7fc4-2fd8-4ded-ac0d-8be31c9a195d%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/CALHSORp0V52QCe%2BKhWw%3DNOXHbuhhPsj%2BuHV%3DXTgdmVE7nr%3D4iA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Spurious power button press with new Debian

[William Hermans]

>
> *With the newest Debian distro, whenever I do that, I get a message that
> the power button has been pressed, and the BBB simply shuts down after
> that. *
>


> Any ideas on what might have changed in the OS for this to happen?


Code I could not say what exactly has changed, but I can say the code in
the context of the button press NMI *has* definitely changed since.

 I can give you something to experiment with that may actually fix that
issue for you.

william@beaglebone:~$ sudo sysctl -a | grep nmi
kernel.nmi_watchdog = 0

If kernel.nmi_watchdog = comes back equal to 1 for you. Then simply
changing this to zero ( 0 ) may solve the problem. so changing the cmdline=
line in /boot/uEnv.txt to. . .

cmdline=kernel.nmi_watchdog = 0

Do keep in mind that this is supposed to be an x86 / x86-64 cmd line option
only, so may not work. But the sysfs entries are there, so I'm thinking it
should work . . .

On Thu, Apr 21, 2016 at 9:55 AM,  wrote:

> Hello guys,
> I have a custom carrier board powering my Beaglebone Black through the 5V
> supply pins on P9 (pins 5+6, I believe).
>
> Because I'm having issues getting my working legacy Angstrom distribution
> image cloned onto new boards that have Micron flash instead of Kingston, I
> decided to give a newer Debian a quick try.
> I have a 3.3V power regulator with an enable input on the board, so the
> BBB needs to assert a particular GPIO high to enable that power rail.
> With the newest Debian distro, whenever I do that, I get a message that
> the power button has been pressed, and the BBB simply shuts down after that.
>
> My 5V regulator can supply up to 5A, and this switchable 3.3V rail doesn't
> even really have any load on it yet until I install the rest of the
> hardware, so I don't believe it should have created any substantial drop in
> the 5V power.
>
> I can do the same operation on the same (older) BBB with Angstrom
> installed and I do not have this problem.
>
> Any ideas on what might have changed in the OS for this to happen?
> I may go back down the road of figuring out how to clone my Angstrom build
> over to the new boards, but still kind of curious why this might have
> happened.
>
> --
> 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/37ab7fc4-2fd8-4ded-ac0d-8be31c9a195d%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/CALHSORqSzf2ZmF_2%2BNkvWRyTfkG1ZdGj%2Bor-topkmiGARB6ysg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB GPIO access with java

[William Hermans]

Any file system *LIBRARY* . . . . typo.

On Thu, Apr 21, 2016 at 3:27 PM, William Hermans  wrote:

>  Any file system linrary would work, with the knowledge of how sysfs works.
>
> On Thu, Apr 21, 2016 at 10:13 AM,  wrote:
>
>> Hello!
>>
>> Did someone know a good free LIB for accessing the GPIO from the
>> Beaglebone Black?
>> I know:
>> http://libbulldog.org/bulldog/
>>
>> But not sure if I make mistakes ... very often I cannot inititalize:
>> private final Board board = Platform.createBoard();
>>
>> This happens, when I destroy my class. I do before this:
>> board.shutdown();
>>
>> And add a new instance of my class.
>> Then it often happen that the command give an error.
>>
>> So is there another lib for control GPIO in Java?
>>
>> Thank you!
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/9f6d0da8-3a08-4467-b950-2af84e666374%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/CALHSORouUuFmHcKWRfGC7Y0dZqh6LSbU_1VLBT43a7zE-a-1%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB GPIO access with java

[William Hermans]

 Any file system linrary would work, with the knowledge of how sysfs works.

On Thu, Apr 21, 2016 at 10:13 AM,  wrote:

> Hello!
>
> Did someone know a good free LIB for accessing the GPIO from the
> Beaglebone Black?
> I know:
> http://libbulldog.org/bulldog/
>
> But not sure if I make mistakes ... very often I cannot inititalize:
> private final Board board = Platform.createBoard();
>
> This happens, when I destroy my class. I do before this:
> board.shutdown();
>
> And add a new instance of my class.
> Then it often happen that the command give an error.
>
> So is there another lib for control GPIO in Java?
>
> Thank you!
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/9f6d0da8-3a08-4467-b950-2af84e666374%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/CALHSORroaKBQ%3DCUHHBNTYRG7d28i_oMsRfUcQx8Jjv6H-BoUhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BeagleBone Black RTC Wake Alarms

[William Hermans]

I can tell you that using kernel 4.1.x
https://www.linux.com/learn/wake-linux-rtc-alarm-clock works. I'm not sure
that rtc wake timer is related to the one you're asking. However, I can
tell you that once the main am335x processor loses power, or the ability to
act from being in sleep mode, the RTC on the processor die will no longer
function correctly. There has been some discussion on these forums about
this in the past, and I do believe there was actually an errata on this as
well.

On Thu, Apr 21, 2016 at 9:52 AM,  wrote:

> I am trying to use power management (sleep mode) in a way that is similar
> to how Android does it with timerfd and epoll. I want to enable autosleep
> and use RTC wake timers (created using timerfd) that wake the system back
> up and prevent sleep mode (using epoll mechanism) until the timer event is
> handled and all wakelocks have been released again.
>
> When I try using this approach, the wake timer created using timerfd does
> not wake the system (however, the rtcwake command does work). I'm not sure
> if this is supported by the BeagleBone kernel or not. I found the following
> code references from Linux 3.12 code, but appears to be replaced with dts
> and drivers/soc/ti/wkup_m3_ipc.c in Linux 3.14. Could there be something
> missing from arch/arm/boot/dts/am33xx.dtsi that would enable what I need?
>
>
> Reference from 3.12 source:
>
> struct wkup_m3_wakeup_src wakeups[] = {
> {.irq_nr = 35,  .src = "USB0_PHY"},
> {.irq_nr = 36,  .src = "USB1_PHY"},
> {.irq_nr = 40,  .src = "I2C0"},
> {.irq_nr = 41,  .src = "RTC Timer"},
> {.irq_nr = 42,  .src = "RTC Alarm"},
> {.irq_nr = 43,  .src = "Timer0"},
> {.irq_nr = 44,  .src = "Timer1"},
> {.irq_nr = 45,  .src = "UART"},
> {.irq_nr = 46,  .src = "GPIO0"},
> {.irq_nr = 48,  .src = "MPU_WAKE"},
> {.irq_nr = 49,  .src = "WDT0"},
> {.irq_nr = 50,  .src = "WDT1"},
> {.irq_nr = 51,  .src = "ADC_TSC"},
> {.irq_nr = 0,   .src = "Unknown"},
> };
>
>
> Environment
> -
> 3.14.55-ti-r78 kernel
> Debian 8.3 filesystem
> rtcwake command works successfully
>
> --
> 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/23d3c790-6165-4920-a85f-47ae17c0cbb8%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/CALHSORqMGytY5r89EMOOQW8_yuY%2BEK1we6yjwE6QnruDpaEP%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Connecting USB device into GPIO ?

[William Hermans]

There are some BLE SPI modules out there, and *maybe* some I2C BLE modules.
The BBB does have both SPI and I2C.

On Thu, Apr 21, 2016 at 1:41 PM, Robert Nelson 
wrote:

>
>
> On Thu, Apr 21, 2016 at 1:08 PM,  wrote:
>
>> As topic leads, can a USB device be hooked into GPIO's?
>> I need Wifi and BLE devices in BBG but dues one USB  its one or other. So
>> since BLE uses less power i wonder if im able to connect BLE dongle into
>> GPIO's instead ?
>> I would guess this is question for both hardware and software topics.
>>
>
> No...
>
> 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/CAOCHtYjDOo2gVy4LosOFG5AmxVe4GvTmASeJQtFS-A50deExBQ%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/CALHSORoypcDGXUfQw9mJRpPhujeE3hJk05D1a9xB1QBSMLnxKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Rick Mann]

I don't have the BBB connected at the moment, but if I don't get you the 
configuration by tonight, please feel free to email me again.

> On Apr 21, 2016, at 14:40 , Rafael Vega  wrote:
> 
> I've made some progress but I still can't get any sound from the codec. I 
> tried the two approaches suggested by Rick M earlier on this thread:
> 
> 1) To use this dtb by Rick M and the audio cape overlay, and 2) to use this 
> dtb (by RobertCNelson) with no overlay. In both cases I have the same 
> apparent outcome: I can see I2C and I2S signals being driven by the BBB when 
> I use aplay or speaker-test but I can't see any analog signal coming out of 
> the codec.
> 
> I have played around with alsamixer, I have deleted 
> /var/lib/alsa/asound.state, used the one from here and no luck... 
> 
> I guess the next step would be to check the driver code and the codec 
> datasheet to try to figure out what might be wrong. I found the code for the 
> driver here (is that it?) but I have no experience in kernel-land development 
> so I'm not sure what the compiling/debugging workflow would be...  My initial 
> questions are:
> 
> 1. How do you compile and install the driver/module without recompiling and 
> installing the whole kernel?
> 2. How does the driver code integrates with the device tree system? I can't 
> see anyting in the driver code that suggests it's taking values or it's 
> functions are being called from the dtb or the overlay.
> 3. What is the simplest 'log' function callable from kernel land and where do 
> I see the output? 
> 
> Any advice on  this would be appreciated!
> 
> :)
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/78d35232-c66d-49e8-841c-f77f99e5e368%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


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


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed 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/5FD85278-8E85-486A-A0C7-62C6CB95D83F%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Rafael Vega]

I've made some progress but I still can't get any sound from the codec. I 
tried the two approaches suggested by Rick M earlier on this thread:

1) To use this  dtb by Rick M and the audio 
cape overlay, and 2) to use this 
 
dtb (by RobertCNelson) with no overlay. In both cases I have the same 
apparent outcome: I can see I2C and I2S signals being driven by the BBB 
when I use aplay or speaker-test but I can't see any analog signal coming 
out of the codec.

I have played around with alsamixer, I have deleted 
/var/lib/alsa/asound.state, used the one from here 

 
and no luck... 

I guess the next step would be to check the driver code and the codec 
datasheet to try to figure out what might be wrong. I found the code for 
the driver here 
 
(is that it?) but I have no experience in kernel-land development so I'm 
not sure what the compiling/debugging workflow would be...  My initial 
questions are:

1. How do you compile and install the driver/module without recompiling and 
installing the whole kernel?
2. How does the driver code integrates with the device tree system? I can't 
see anyting in the driver code that suggests it's taking values or it's 
functions are being called from the dtb or the overlay.
3. What is the simplest 'log' function callable from kernel land and where 
do I see the output? 

Any advice on  this would be appreciated!

:)

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

Re: [beagleboard] Connecting USB device into GPIO ?

[Robert Nelson]

On Thu, Apr 21, 2016 at 1:08 PM,  wrote:

> As topic leads, can a USB device be hooked into GPIO's?
> I need Wifi and BLE devices in BBG but dues one USB  its one or other. So
> since BLE uses less power i wonder if im able to connect BLE dongle into
> GPIO's instead ?
> I would guess this is question for both hardware and software topics.
>

No...

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

[beagleboard] BeagleBone Black RTC Wake Alarms

[darren . landoll]

I am trying to use power management (sleep mode) in a way that is similar 
to how Android does it with timerfd and epoll. I want to enable autosleep 
and use RTC wake timers (created using timerfd) that wake the system back 
up and prevent sleep mode (using epoll mechanism) until the timer event is 
handled and all wakelocks have been released again.

When I try using this approach, the wake timer created using timerfd does 
not wake the system (however, the rtcwake command does work). I'm not sure 
if this is supported by the BeagleBone kernel or not. I found the following 
code references from Linux 3.12 code, but appears to be replaced with dts 
and drivers/soc/ti/wkup_m3_ipc.c in Linux 3.14. Could there be something 
missing from arch/arm/boot/dts/am33xx.dtsi that would enable what I need?


Reference from 3.12 source:

struct wkup_m3_wakeup_src wakeups[] = {
{.irq_nr = 35,  .src = "USB0_PHY"},
{.irq_nr = 36,  .src = "USB1_PHY"},
{.irq_nr = 40,  .src = "I2C0"},
{.irq_nr = 41,  .src = "RTC Timer"},
{.irq_nr = 42,  .src = "RTC Alarm"},
{.irq_nr = 43,  .src = "Timer0"},
{.irq_nr = 44,  .src = "Timer1"},
{.irq_nr = 45,  .src = "UART"},
{.irq_nr = 46,  .src = "GPIO0"},
{.irq_nr = 48,  .src = "MPU_WAKE"},
{.irq_nr = 49,  .src = "WDT0"},
{.irq_nr = 50,  .src = "WDT1"},
{.irq_nr = 51,  .src = "ADC_TSC"},
{.irq_nr = 0,   .src = "Unknown"},
};


Environment
-
3.14.55-ti-r78 kernel
Debian 8.3 filesystem
rtcwake command works successfully

-- 
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/23d3c790-6165-4920-a85f-47ae17c0cbb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Connecting USB device into GPIO ?

[prototive]

As topic leads, can a USB device be hooked into GPIO's?
I need Wifi and BLE devices in BBG but dues one USB  its one or other. So 
since BLE uses less power i wonder if im able to connect BLE dongle into 
GPIO's instead ?
I would guess this is question for both hardware and software topics.

-- 
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/01723c40-9606-4b47-88de-01173ec11a3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Spurious power button press with new Debian

[sbattazzo]

Hello guys,
I have a custom carrier board powering my Beaglebone Black through the 5V 
supply pins on P9 (pins 5+6, I believe). 

Because I'm having issues getting my working legacy Angstrom distribution 
image cloned onto new boards that have Micron flash instead of Kingston, I 
decided to give a newer Debian a quick try.
I have a 3.3V power regulator with an enable input on the board, so the BBB 
needs to assert a particular GPIO high to enable that power rail.
With the newest Debian distro, whenever I do that, I get a message that the 
power button has been pressed, and the BBB simply shuts down after that.

My 5V regulator can supply up to 5A, and this switchable 3.3V rail doesn't 
even really have any load on it yet until I install the rest of the 
hardware, so I don't believe it should have created any substantial drop in 
the 5V power.

I can do the same operation on the same (older) BBB with Angstrom installed 
and I do not have this problem.

Any ideas on what might have changed in the OS for this to happen?
I may go back down the road of figuring out how to clone my Angstrom build 
over to the new boards, but still kind of curious why this might have 
happened.

-- 
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/37ab7fc4-2fd8-4ded-ac0d-8be31c9a195d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB GPIO access with java

[hoerting . business]

Hello!

Did someone know a good free LIB for accessing the GPIO from the Beaglebone 
Black?
I know:
http://libbulldog.org/bulldog/

But not sure if I make mistakes ... very often I cannot inititalize:
private final Board board = Platform.createBoard();

This happens, when I destroy my class. I do before this:
board.shutdown();

And add a new instance of my class.
Then it often happen that the command give an error.

So is there another lib for control GPIO in Java?

Thank you!

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

[beagleboard] Re: Is is possible to communicate over serial (big USB ) between BBB and Teensy 2.0?

[farzin . negahbani]

Hi, 
on the BBB the USB host device appears as ttyACM* for many of serial 
devices, or ttyUSB*
you can assured by using:  
ls -l /dev/ttyACM* 
ls -l /dev/ttyUSB*
after you found your device you can use pyserial or any other libraries to 
communicate!
good luck!

On Sunday, November 9, 2014 at 4:19:13 AM UTC+3:30, Sorin Vatasoiu wrote:
>
> Hi,
> I have a Teensy 2.0 board that control a device. Teensy it is set to 
> accept serial (115200) commands as text: "motoron", "motoroff" ... and 
> execute them, which is working fine. 
> Now I try to use a BBB rev. C (Linux Debian) to be the source that will 
> send those command. I would like to use the big usb connector (usb host?) 
> as it does offer also 5V power needed for Teensy 2.0.
> Is this scenario possible? 
> For start it will be OK if the command is sent from BBB like "echo motoron 
> > /dev/tty ", later I would like to have a python program to do this.
> I'm very beginner with Linux, so if you know a solution please consider 
> this level and provide detailed instruction about how can I do it.
> Suggestions or solutions are welcome. 
>
> Thank you in advance,
> Sorin
>

-- 
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/51a9f61c-8a03-40ae-af44-dcc4af0cfabb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[William Hermans]

>
> *Yeah, that's the file that's working for me, EXCEPT: I modified my
> am33xx-overlay-edma-fix.dtsi to comment out the two mcasp entries. If I
> boot with that (on 4.4.7-bone-rt-r9), then I can load the BB-BONE-AUDI-02
> overlay, and then I can use aplay and speaker-test.*
>
> * At this point, though, the channels are not quite right. Only the left
> works. This is hopefully due to a very badly configured ALSA.*
>

Wish I had a physical cape, I'm very good at troubleshooting these sorts of
issues. I'm thinking it's probably in the driver though. No reason, other
than gut instinct.

*BTW, your buddy surely didn't use my cape; I've only built one, and it's
> here. :-) The last few days I've been using the CircuitCo AudioCape Rev B
> (the Rev A has a different codec). My cape is almost identical to the Rev
> B, so I'll soon try it again.*
>

Well, you know, I wasn't there . . . word of mouth sort of thing.

Anyway, I'll probably just comment out the edma fix file,  and just manualy
load the SPI's later, or . . . actually I do not think we use any of the
SPI modules from the processor.

On Thu, Apr 21, 2016 at 7:29 AM, Rafael Vega  wrote:

>
>
>> Are you able to make it work with my original .dtb and loading the
>> BB-BONE-AUDI-02 overlay via capemgr?
>>
>>
> When I do this, the overlay loads fine and I can see the mcasp0 pins being
> driven by the BBB when I start aplay or speaker-test. However, I can't see
> any analog signals coming out of the codec. May I ask what ALSA or
> alsamixer configuration you are using to achieve output on the left channel?
>
> Thanks for taking me this far!! :)
>
>
> --
> 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/50d483c1-29a2-4305-81af-cc5145720d76%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/CALHSORouFcO-X33gX5X6AOWY933Yv5z2dDmctuo45SDzwO%2BwMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BeagleBone Black n00b - maybe already corrupted eMMC?

[William Hermans]

>
> *The cheapest solution right now to safe guard from  unexpected power
> outages. Is to buy a battery, and connect it to the PMIC test points. This
> will give the beaglebone enough time to issue a clean shutdown after input
> power goes missing. And that it exactly what it will do, power down.*
>

Technically the cheapest option is free. Use USB power, plug into a laptop,
and be sure to always issue shutdown now -h every time you need to power
down.

On Thu, Apr 21, 2016 at 9:25 AM, William Hermans  wrote:

> *In the real world, BBBs and other devices will experience unexpected and
>> unplanned power outages, should be designed, and up to a reasonable point
>> are designed to survive them. I have both intentionally and unintentionally
>> rudely removed power from BBBs many, many times (hundreds?) with no ill
>> effects.*
>>
>
> I think you all expect far too much from an originally $45 SBC, and now a
> $55 SBC. All this stuff you all are talking about, including just changing
> an information card to tell people not to just yank power. Costs monies.
>
> The cheapest solution right now to safe guard from  unexpected power
> outages. Is to buy a battery, and connect it to the PMIC test points. This
> will give the beaglebone enough time to issue a clean shutdown after input
> power goes missing. And that it exactly what it will do, power down.
>
> Anyway, the above solution can be done for $10 or less, and if Gerald /
> circuitco designed this from the start, onto the beaglebone. It would at
> minimum have driven the price up $5 per board or more. For an option many
> people would not need or use.
>
> So, if you need feature yourself. google "beaglebone UPS" and you'll find
> all kind of information. Then buy yourself a battery, and learn how to do
> this yourself . .
>
> On Thu, Apr 21, 2016 at 6:51 AM, mickeyf  wrote:
>
>> The fact that the USB Gadget IP address shows up and that you can connect
>> via ssh indicates that the OS is basically working. You may not have
>> corrupted anything, but are simply not using the right password (which I
>> don't remember either, but which I do remember was either non-intuitive or
>> hard to track down)
>>
>> In the real world, BBBs and other devices will experience unexpected and
>> unplanned power outages, should be designed, and up to a reasonable point
>> are designed to survive them. I have both intentionally and unintentionally
>> rudely removed power from BBBs many, many times (hundreds?) with no ill
>> effects.
>>
>> On the other hand, I do recall a certain 4 year old famously saying 'But
>> I've run out in the street lots of times and never been hit by a car,
>> Daddy!" You may want to avoid tempting fate unnecessarily.
>>
>> In any case it is certainly quicker and easier to reflash a BBB than to,
>> for example, rebuild an entire hard drive and reinstall a recent version of
>> Windows on it.
>>
>> On Wednesday, April 20, 2016 at 9:52:58 PM UTC-7, William Hermans wrote:
>>>
>>> *Hey William,*

 *Yes, that's all very clear in hindsight. I do wish that I had looked
 up how to turn it off properly before I made the mistake. *

 *Thank you for the clarification on the kernel. It's hard to find
 up-to-date info.*

 *-Nate*

>>>
>>> Ok, so now that we have that clear ;) hehe.
>>>
>>> You have to treat this like you would any other computer. Except perhaps
>>> the beaglebone is more fragile. Due to hardware costs, and the fact that
>>> the software, that is specific to the beaglebone is written by various
>>> members of the community. Who by the way do not get paid to do that.
>>>
>>> But you would shut down the BBB the same way you would shutdown your
>>> laptop from the command line.
>>>
>>> $ sudo shutdown now -h
>>>
>>> *or*
>>>
>>> $ sudo halt
>>>
>>> There is also a button closest to the ethernet jack which triggers an
>>> NMI through the PMIC, which should signal the processor to cleaning shut
>>> down linux. The button furthest from the ethernet jack on the same side (
>>> left ) if I remember correctly is the reset button. So make sure not to
>>> press that while the OS is running either. The effect would be similar to
>>> pulling the power.
>>>
>>> On Wed, Apr 20, 2016 at 9:38 PM, Nathan Wheeler 
>>> wrote:
>>>
 Hey William,

 Yes, that's all very clear in hindsight. I do wish that I had looked up
 how to turn it off properly before I made the mistake.

 Thank you for the clarification on the kernel. It's hard to find
 up-to-date info.

 -Nate

 On Wednesday, April 20, 2016 at 9:15:44 PM UTC-7, William Hermans wrote:
>
> So, question. If you removed the battery from your laptop, and then
> ran your laptop with no battery, an just yanked the power cord out of the
> wall to shut it down. What do you think would happen ? It's the same
> difference, except it would possibly take many more attempts at corrupting
> you laptop, before it did actually corr

Re: [beagleboard] BeagleBone Black n00b - maybe already corrupted eMMC?

[William Hermans]

>
> *In the real world, BBBs and other devices will experience unexpected and
> unplanned power outages, should be designed, and up to a reasonable point
> are designed to survive them. I have both intentionally and unintentionally
> rudely removed power from BBBs many, many times (hundreds?) with no ill
> effects.*
>

I think you all expect far too much from an originally $45 SBC, and now a
$55 SBC. All this stuff you all are talking about, including just changing
an information card to tell people not to just yank power. Costs monies.

The cheapest solution right now to safe guard from  unexpected power
outages. Is to buy a battery, and connect it to the PMIC test points. This
will give the beaglebone enough time to issue a clean shutdown after input
power goes missing. And that it exactly what it will do, power down.

Anyway, the above solution can be done for $10 or less, and if Gerald /
circuitco designed this from the start, onto the beaglebone. It would at
minimum have driven the price up $5 per board or more. For an option many
people would not need or use.

So, if you need feature yourself. google "beaglebone UPS" and you'll find
all kind of information. Then buy yourself a battery, and learn how to do
this yourself . .

On Thu, Apr 21, 2016 at 6:51 AM, mickeyf  wrote:

> The fact that the USB Gadget IP address shows up and that you can connect
> via ssh indicates that the OS is basically working. You may not have
> corrupted anything, but are simply not using the right password (which I
> don't remember either, but which I do remember was either non-intuitive or
> hard to track down)
>
> In the real world, BBBs and other devices will experience unexpected and
> unplanned power outages, should be designed, and up to a reasonable point
> are designed to survive them. I have both intentionally and unintentionally
> rudely removed power from BBBs many, many times (hundreds?) with no ill
> effects.
>
> On the other hand, I do recall a certain 4 year old famously saying 'But
> I've run out in the street lots of times and never been hit by a car,
> Daddy!" You may want to avoid tempting fate unnecessarily.
>
> In any case it is certainly quicker and easier to reflash a BBB than to,
> for example, rebuild an entire hard drive and reinstall a recent version of
> Windows on it.
>
> On Wednesday, April 20, 2016 at 9:52:58 PM UTC-7, William Hermans wrote:
>>
>> *Hey William,*
>>>
>>> *Yes, that's all very clear in hindsight. I do wish that I had looked up
>>> how to turn it off properly before I made the mistake. *
>>>
>>> *Thank you for the clarification on the kernel. It's hard to find
>>> up-to-date info.*
>>>
>>> *-Nate*
>>>
>>
>> Ok, so now that we have that clear ;) hehe.
>>
>> You have to treat this like you would any other computer. Except perhaps
>> the beaglebone is more fragile. Due to hardware costs, and the fact that
>> the software, that is specific to the beaglebone is written by various
>> members of the community. Who by the way do not get paid to do that.
>>
>> But you would shut down the BBB the same way you would shutdown your
>> laptop from the command line.
>>
>> $ sudo shutdown now -h
>>
>> *or*
>>
>> $ sudo halt
>>
>> There is also a button closest to the ethernet jack which triggers an NMI
>> through the PMIC, which should signal the processor to cleaning shut down
>> linux. The button furthest from the ethernet jack on the same side ( left )
>> if I remember correctly is the reset button. So make sure not to press that
>> while the OS is running either. The effect would be similar to pulling the
>> power.
>>
>> On Wed, Apr 20, 2016 at 9:38 PM, Nathan Wheeler 
>> wrote:
>>
>>> Hey William,
>>>
>>> Yes, that's all very clear in hindsight. I do wish that I had looked up
>>> how to turn it off properly before I made the mistake.
>>>
>>> Thank you for the clarification on the kernel. It's hard to find
>>> up-to-date info.
>>>
>>> -Nate
>>>
>>> On Wednesday, April 20, 2016 at 9:15:44 PM UTC-7, William Hermans wrote:

 So, question. If you removed the battery from your laptop, and then ran
 your laptop with no battery, an just yanked the power cord out of the wall
 to shut it down. What do you think would happen ? It's the same difference,
 except it would possibly take many more attempts at corrupting you laptop,
 before it did actually corrupt the file system.

 Also, it's running Debian wheezy with a 3.8.x kernel, not Angstrom.
 Just so you know. RevC's all came with a *bone-47* 3.8 kernel.

 On Wed, Apr 20, 2016 at 9:04 PM, Nathan Wheeler 
 wrote:

> Hey all,
>
> I did a search - maybe someone is better at it than I am and could
> help connect me to an explanation/solution? Anyway, here's what has
> happened:
>
> I got my board in the mail yesterday and connected it to my new
> MacBook Pro Retina (running OSX 10.11.3). I was able to ssh over USB after
> installing the included drivers and write/

Re: [beagleboard] CDC_ETHER in Debian 3.8.13-bone70

[Matt99eo]

Yep I read that and here is my /network/interfaces

root@arm:~# cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback
  
#auto eth0
#iface eth0 inet dhcp

On Wednesday, April 20, 2016 at 6:11:14 PM UTC-7, William Hermans wrote:
>
> well according to this: 
> http://nimbelink.com/appnotes/CAT1CDC-ECM-Application_Note.pdf
>
> You need to comment out the USB0 lines in /etc/network/interfaces, and 
> then the device will automatically come up
>
> On Wed, Apr 20, 2016 at 5:07 PM, Matt99eo  > wrote:
>
>> Yes it is a modem
>>
>> http://nimbelink.com/skywire-4g-lte-cat-1/
>>
>> They do not have firmware yet that supports pppd.  I use ppp for other 
>> modems that do support it and that works this guys is just different (until 
>> firmware is baked).  
>>
>>
>>
>> On Wednesday, April 20, 2016 at 4:53:41 PM UTC-7, William Hermans wrote:
>>>
>>> usb1 is probably your external device. But you can find out via dmesg by 
>>> issuing . .
>>>
>>> $ dmesg | grep usb1
>>>
>>> And using deductive reasoning. But also, once you get your cdc device 
>>> working, I do not know how it's meant to be used. Robert Suggested pppd 
>>> which suggests to me it's meant to be used a some sort of modem ?
>>>
>>> On Wed, Apr 20, 2016 at 4:50 PM, Matt99eo  wrote:
>>>
 I was wondering about multiple usb connections...

 So here is thing though.  I am now ssh'd into the device over ethernet. 
 I see the usbo with ifconfig:

 ifconfig 
 eth0  Link encap:Ethernet  HWaddr 78:a5:04:f8:61:5e  
   inet addr:10.1.2.169  Bcast:10.1.2.255  Mask:255.255.255.0
   inet6 addr: fe80::7aa5:4ff:fef8:615e/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:881 errors:0 dropped:9 overruns:0 frame:0
   TX packets:282 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000 
   RX bytes:87981 (85.9 KiB)  TX bytes:37544 (36.6 KiB)
   Interrupt:40 

 loLink encap:Local Loopback  
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   UP LOOPBACK RUNNING  MTU:65536  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:0 
   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 usb0  Link encap:Ethernet  HWaddr 02:80:70:00:04:70  
   inet addr:192.168.7.2  Bcast:192.168.7.255  Mask:255.255.255.0
   inet6 addr: fe80::80:70ff:fe00:470/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000 
   RX bytes:0 (0.0 B)  TX bytes:5387 (5.2 KiB)


 But now how do I test I am connected out that way instead of over the 
 ethernet cable lol?

 At the end of the day I want these devices to talk out the cell module 
 to cloud servers and be able to acess them in the field via ssh.  I have 
 statically provisioned SIM cards so I can get to them. 

 On Wednesday, April 20, 2016 at 4:41:40 PM UTC-7, William Hermans wrote:
>
> And sorry . . 
>
> william@beaglebone:~$ sudo ifconfig usb0 192.168.7.2
> THEN
> william@beaglebone:~$ sudo ifconfig
> . . .
>
> usb0  Link encap:Ethernet  HWaddr 7e:68:32:bc:58:89
>   inet addr:192.168.7.2  Bcast:192.168.7.255  
> Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1 errors:0 dropped:1 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:76 (76.0 B)  TX bytes:0 (0.0 B)
>
>
>
>
> On Wed, Apr 20, 2016 at 4:39 PM, William Hermans  
> wrote:
>
>> For instance: 
>>
>> william@beaglebone:~$ ls /sys/class/net
>> eth0  lo
>> william@beaglebone:~$ sudo modprobe g_ether
>>
>> william@beaglebone:~$ ls /sys/class/net
>> eth0  lo  usb0
>>
>> william@beaglebone:~$ sudo ifconfig
>>  . . .
>> usb0  Link encap:Ethernet  HWaddr 7e:68:32:bc:58:89
>>   inet addr:192.168.7.2  Bcast:192.168.7.255  
>> Mask:255.255.255.0
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:1 errors:0 dropped:1 overruns:0 frame:0
>>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:76 (76.0 B)  TX bytes:0 (0.0 B)
>>
>> However, I've no ide

Re: [beagleboard] Flashin BBB with new image I built from RC guide

[Matt99eo]

Doh thank you that did it

Thanks again for the hand holding.

On Wednesday, April 20, 2016 at 3:56:47 PM UTC-7, RobertCNelson wrote:
>
>
>
> On Wed, Apr 20, 2016 at 5:40 PM, Matt99eo  > wrote:
>
>> Yes I saw this stuff and used the 
>>
>> /dev/sdX options to get it all on the uSD card.
>>
>> Now that it is on there and I am booted into the serial consol on the bbb 
>> running I built do I do all this again but with /mmblk0 option?
>>
>
> No... If you actually click on the link..
>
> https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-eMMC
>
> It says:
> eMMC
>
> Script to copy your microSD card to eMMC: (this will need these packages 
> installed: initramfs-tools dosfstools rsync)
> wget https://
> raw.githubusercontent.com/RobertCNelson/boot-scripts/master/tools/eMMC/bbb-eMMC-flasher-eewiki-ext4.sh
> chmod +x bbb-eMMC-flasher-eewiki-ext4.sh
> sudo /bin/bash ./bbb-eMMC-flasher-eewiki-ext4.sh
>  
> 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/a7b03f5d-4bc5-4cb1-8f47-26d13e43a2a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Rafael Vega]

>
> Are you able to make it work with my original .dtb and loading the 
> BB-BONE-AUDI-02 overlay via capemgr? 
>
>
When I do this, the overlay loads fine and I can see the mcasp0 pins being 
driven by the BBB when I start aplay or speaker-test. However, I can't see 
any analog signals coming out of the codec. May I ask what ALSA or 
alsamixer configuration you are using to achieve output on the left channel?

Thanks for taking me this far!! :)
 

-- 
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/50d483c1-29a2-4305-81af-cc5145720d76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BeagleBone Black n00b - maybe already corrupted eMMC?

[mickeyf]

The fact that the USB Gadget IP address shows up and that you can connect 
via ssh indicates that the OS is basically working. You may not have 
corrupted anything, but are simply not using the right password (which I 
don't remember either, but which I do remember was either non-intuitive or 
hard to track down)

In the real world, BBBs and other devices will experience unexpected and 
unplanned power outages, should be designed, and up to a reasonable point 
are designed to survive them. I have both intentionally and unintentionally 
rudely removed power from BBBs many, many times (hundreds?) with no ill 
effects.

On the other hand, I do recall a certain 4 year old famously saying 'But 
I've run out in the street lots of times and never been hit by a car, 
Daddy!" You may want to avoid tempting fate unnecessarily. 

In any case it is certainly quicker and easier to reflash a BBB than to, 
for example, rebuild an entire hard drive and reinstall a recent version of 
Windows on it. 

On Wednesday, April 20, 2016 at 9:52:58 PM UTC-7, William Hermans wrote:
>
> *Hey William,*
>>
>> *Yes, that's all very clear in hindsight. I do wish that I had looked up 
>> how to turn it off properly before I made the mistake. *
>>
>> *Thank you for the clarification on the kernel. It's hard to find 
>> up-to-date info.*
>>
>> *-Nate*
>>
>
> Ok, so now that we have that clear ;) hehe. 
>
> You have to treat this like you would any other computer. Except perhaps 
> the beaglebone is more fragile. Due to hardware costs, and the fact that 
> the software, that is specific to the beaglebone is written by various 
> members of the community. Who by the way do not get paid to do that.
>
> But you would shut down the BBB the same way you would shutdown your 
> laptop from the command line.
>
> $ sudo shutdown now -h
>
> *or*
>
> $ sudo halt
>
> There is also a button closest to the ethernet jack which triggers an NMI 
> through the PMIC, which should signal the processor to cleaning shut down 
> linux. The button furthest from the ethernet jack on the same side ( left ) 
> if I remember correctly is the reset button. So make sure not to press that 
> while the OS is running either. The effect would be similar to pulling the 
> power.
>
> On Wed, Apr 20, 2016 at 9:38 PM, Nathan Wheeler  > wrote:
>
>> Hey William,
>>
>> Yes, that's all very clear in hindsight. I do wish that I had looked up 
>> how to turn it off properly before I made the mistake. 
>>
>> Thank you for the clarification on the kernel. It's hard to find 
>> up-to-date info.
>>
>> -Nate
>>
>> On Wednesday, April 20, 2016 at 9:15:44 PM UTC-7, William Hermans wrote:
>>>
>>> So, question. If you removed the battery from your laptop, and then ran 
>>> your laptop with no battery, an just yanked the power cord out of the wall 
>>> to shut it down. What do you think would happen ? It's the same difference, 
>>> except it would possibly take many more attempts at corrupting you laptop, 
>>> before it did actually corrupt the file system.
>>>
>>> Also, it's running Debian wheezy with a 3.8.x kernel, not Angstrom. Just 
>>> so you know. RevC's all came with a *bone-47* 3.8 kernel.
>>>
>>> On Wed, Apr 20, 2016 at 9:04 PM, Nathan Wheeler  
>>> wrote:
>>>
 Hey all,

 I did a search - maybe someone is better at it than I am and could help 
 connect me to an explanation/solution? Anyway, here's what has happened:

 I got my board in the mail yesterday and connected it to my new MacBook 
 Pro Retina (running OSX 10.11.3). I was able to ssh over USB after 
 installing the included drivers and write/run code on the board. I didn't 
 write anything special, just practiced loading a python example to the 
 board.

 I didn't know that pulling the USB cable without turning the board off 
 via the Power button could corrupt the eMMC onboard. I understand I should 
 have read the manual, but I think this information needs to be included on 
 any "quick start" info provided to beginners. (If they tell you how to 
 turn 
 it on, shouldn't they tell you how to safely turn it off?) I have a lot of 
 experience with Arduino and mistakenly thought that I could unplug the 
 BeagleBone from power without any other shutdown steps.

 So now, the board powers on and the user LEDs flash, and the board 
 shows up as an external storage device on my laptop. But the IP address 
 has 
 changed to 198.168.7.1, and any attempts to ssh either result in a timeout 
 or require password authentication. And the default passwords provided on 
 Adafruit and other places are not working.

 So, my questions are:
 • How do I know if I've corrupted the data in the eMMC? Will the board 
 act normally but not connect?
 • If I can't ssh via USB, will I be able to do so via ethernet, or 
 should I just start over/do a restore of Angstrom? 
 • Is Angstrom stiil the default distro, or are th

Re: [beagleboard] Re: BeagleBoard (Angstrom Linux distribution) - How to get USB WEB camera working

[evilwulfie]

Hardly anybody on this list uses the ancient angstrom image.

maybe update to a newer Debian image ?



On 4/20/2016 11:09 PM, truevib...@gmail.com wrote:
> I wish someone had answered this. 
>
> On Wednesday, September 5, 2012 at 4:53:34 AM UTC-4, Krcevina wrote:
>
> Hi,
>
> I have downloaded MLO, u-boot.img and uImage from
> http://downloads.angstrom-distribution.org/demo/beagleboard/
>  and
> my BB boots okay. When I connect USB WEB camera with BB I get the
> following:
>
> root@beagleboard:~# [  114.069580] usb 1-2: new high speed USB
> device number 2 using
> ehci-omap 
>   
>
> [  114.242279] usb 1-2: New USB device found, idVendor=1a40,
> idProduct=0101
>   
>
> [  114.249420] usb 1-2: New USB device strings: Mfr=0, Product=1,
> SerialNumber=0
>  
>
> [  114.256927] usb 1-2: Product: USB 2.0 Hub
> [MTT] 
>   
>
> [  114.287963] hub 1-2:1.0: USB hub
> found 
>
>
> [  114.304382] hub 1-2:1.0: 4 ports
> detected  
>
>
> [  114.616516] usb 1-2.1: new high speed USB device number 3 using
> ehci-omap 
> 
>
> [  114.917877] usb 1-2.1: New USB device found, idVendor=1307,
> idProduct=0330
> 
>
> [  114.925140] usb 1-2.1: New USB device strings: Mfr=1,
> Product=2,
> SerialNumber=3
>
>
> [  114.932861] usb 1-2.1: Product: Mass Storage
> Device
>
>
> [  114.938018] usb 1-2.1: Manufacturer:
> Generic   
>
>
> [  114.942749] usb 1-2.1: SerialNumber:
> 06
>
>
> [  114.976593] scsi0 : usb-storage
> 1-2.1:1.0 
> 
>
> [  115.077636] usb 1-2.3: new high speed USB device number 4 using
> ehci-omap 
> 
>
> [  115.396728] usb 1-2.3: New USB device found, idVendor=0bda,
> idProduct=58b0
> 
>
> [  115.404052] usb 1-2.3: New USB device strings: Mfr=3,
> Product=1,
> SerialNumber=2
>
>
> [  115.411773] usb 1-2.3: Product: FULL HD 1080P
> Webcam
>   
>
> [  115.416992] usb 1-2.3: Manufacturer:
> Generic   
>
>
> [  115.421508] usb 1-2.3: SerialNumber:
> 200901010001  
>
>
> [  115.984863] scsi 0:0:0:0: Direct-Access Generic  Compact
> Flash0.00 PQ: 0 ANSI:
> 2  
>
> [  115.994659] sd 0:0:0:0: Attached scsi generic sg0 type
> 0 
>  
>
> [  116.004791] sd 0:0:0:0: [sda] Attached SCSI removable
> disk  
>   
>
> [  116.030609] scsi 0:0:0:1: Direct-Access Generic 
> SM/xD-Picture0.00 PQ: 0 ANSI:
> 2  
>
> [  116.040435] sd 0:0:0:1: Attached scsi generic sg1 type
> 0 
>  
>
> [  116.050262] sd 0:0:0:1: [sdb] Attached SCSI removable
> disk

[beagleboard] Re: BeagleBoard (Angstrom Linux distribution) - How to get USB WEB camera working

[truevibedc]

I wish someone had answered this. 

On Wednesday, September 5, 2012 at 4:53:34 AM UTC-4, Krcevina wrote:
>
> Hi,
>
> I have downloaded MLO, u-boot.img and uImage from 
> http://downloads.angstrom-distribution.org/demo/beagleboard/ and my BB 
> boots okay. When I connect USB WEB camera with BB I get the following:
>
> root@beagleboard:~# [  114.069580] usb 1-2: new high speed USB device 
> number 2 using 
> ehci-omap
>
> [  114.242279] usb 1-2: New USB device found, idVendor=1a40, 
> idProduct=0101
>
>
> [  114.249420] usb 1-2: New USB device strings: Mfr=0, Product=1, 
> SerialNumber=0
>   
>
> [  114.256927] usb 1-2: Product: USB 2.0 Hub 
> [MTT] 
>
>
> [  114.287963] hub 1-2:1.0: USB hub 
> found 
> 
>
> [  114.304382] hub 1-2:1.0: 4 ports 
> detected  
> 
>
> [  114.616516] usb 1-2.1: new high speed USB device number 3 using 
> ehci-omap 
>  
>
> [  114.917877] usb 1-2.1: New USB device found, idVendor=1307, 
> idProduct=0330
>  
>
> [  114.925140] usb 1-2.1: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> 
>
> [  114.932861] usb 1-2.1: Product: Mass Storage 
> Device
> 
>
> [  114.938018] usb 1-2.1: Manufacturer: 
> Generic   
> 
>
> [  114.942749] usb 1-2.1: SerialNumber: 
> 06
> 
>
> [  114.976593] scsi0 : usb-storage 
> 1-2.1:1.0 
>  
>
> [  115.077636] usb 1-2.3: new high speed USB device number 4 using 
> ehci-omap 
>  
>
> [  115.396728] usb 1-2.3: New USB device found, idVendor=0bda, 
> idProduct=58b0
>  
>
> [  115.404052] usb 1-2.3: New USB device strings: Mfr=3, Product=1, 
> SerialNumber=2
> 
>
> [  115.411773] usb 1-2.3: Product: FULL HD 1080P 
> Webcam
>
>
> [  115.416992] usb 1-2.3: Manufacturer: 
> Generic   
> 
>
> [  115.421508] usb 1-2.3: SerialNumber: 
> 200901010001  
> 
>
> [  115.984863] scsi 0:0:0:0: Direct-Access Generic  Compact Flash
> 0.00 PQ: 0 ANSI: 
> 2   
> [  115.994659] sd 0:0:0:0: Attached scsi generic sg0 type 
> 0 
>   
>
> [  116.004791] sd 0:0:0:0: [sda] Attached SCSI removable 
> disk  
>
>
> [  116.030609] scsi 0:0:0:1: Direct-Access Generic  SM/xD-Picture
> 0.00 PQ: 0 ANSI: 
> 2   
> [  116.040435] sd 0:0:0:1: Attached scsi generic sg1 type 
> 0 
>   
>
> [  116.050262] sd 0:0:0:1: [sdb] Attached SCSI removable 
> disk  
>
>
> [  116.074127] scsi 0:0:0:2: Direct-Access Generic  SD/MMC   
> 0.00 PQ: 0 ANSI: 
> 2   
> [  116.083923] sd 0:0:0:2: Attached scsi generic sg2 type 
> 0 
>   
>
> [  116.094635] 

Re: [beagleboard] updated config-pin?

[cahmadiz . sfu]

Were you able to solve this problem?

On Friday, October 23, 2015 at 7:51:35 AM UTC-7, Yogi Patel wrote:
>
> On Friday, October 23, 2015 at 9:31:57 AM UTC-4, RobertCNelson wrote:
>>
>> On Thu, Oct 22, 2015 at 8:04 PM,   wrote: 
>> > Hi - 
>> > 
>> > I just our project to 4.1. I made the mods necessary to the dts to 
>> account 
>> > for the gpio changes/etc and can load the overlay. However, when I run 
>> > 
>> > config-pin P9.29 gpio 
>> > 
>> > to set the pin modes and states, I am faced with: 
>> > 
>> > bash: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state: No such file or 
>> > directory 
>> > Cannot write pinmux file: 
>> /sys/devices/platform/ocp/ocp*P9_29_pinmux/state 
>> > 
>> > It looks like the structure of the ocp dirs has changed - so I assume 
>> this 
>> > is expected. But where/how to set the state now is unclear to me. Is 
>> there a 
>> > "newer" version of config-pin available? 
>>
>> Yeap.. 
>>
>> > debian@beaglebone:$ uname -r 
>> > 4.1.10-ti-r24 
>> > 
>> > debian@beaglebone:~/puggledriver/apps$ dtc --version 
>> > Version: DTC 1.4.1-g8e001df3 
>>
>>
>> https://github.com/cdsteinkuehler/beaglebone-universal-io/commits/master/config-pin
>>  
>
>
> Pulled that repo, and used that config-pin script to try and I get the 
> same errors again. I see the changes you made to the script, however those 
> changes are still trying to write to 
> /sys/devices/platform/ocp/ocp*P9_29_pinmux/state - but there is no "state" 
> file in any of the P* directories. Did I forget a step?...
>  
>
>> 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/ec6a7f0a-3f9e-4c43-a3cb-96e3904d3ca1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to use Exim4 to Send Email from Beaglebone Black Debian

[Dieter Wirz]

Create the file .muttrc eg in /root/ or in /home/debian/ (the user
that wants to use mutt) and add a line
set smtp_url="smtp://user:passw...@smtp.someserver.com"
And don't forget the return after this line. (as in crontab as well)

* * * * * root ls /somefolder  | mutt -s ""  someu...@someserver.com 2>&1

BTW: didn't you read my Email where i worte that you can redirect
crontabs output into a file:
* * * * * root ls /somefolder >> /root/crontab_err.txt 2>&1

On Thu, Apr 21, 2016 at 2:06 AM, John Baker
 wrote:
> Dieter,
> I'm trying to get mutt running to get error messages from crontab. I
> installed mutt with aptitude and it may be working but I don't know how to
> set it up to get the messages :-[
>
> Apr 20 23:49:01 beaglebone /USR/SBIN/CRON[8657]: (root) CMD (export
> DISPLAY=:0 && /usr/bin/python /home/debian/Desktop/SimB.py)
> Apr 20 23:50:01 beaglebone /USR/SBIN/CRON[8690]: (root) CMD (export
> DISPLAY=:0 && /usr/bin/python /home/debian/Desktop/SimB.py)
> Apr 20 23:51:02 beaglebone /USR/SBIN/CRON[8723]: (root) CMD (export
> DISPLAY=:0 && /usr/bin/python /home/debian/Desktop/SimB.py)
> Apr 20 23:52:01 beaglebone /USR/SBIN/CRON[8756]: (root) CMD (export
> DISPLAY=:0 && /usr/bin/python /home/debian/Desktop/SimB.py)
>
> Setup is described in https://wiki.debian.org/Mutt says there is a muttrc
> file in "a user's $HOME directory" but I find only unreadable muttrc files
> elsewhere and I'm not sure I know where and what a "user's $HOME directory"
> is.
>
> 1. Do I need to set up some directory in /home/?
> 2. Do I need to create a muttrc file to configure mutt?
> 3. Is there a way to find and read the sent messages?
>
> Thanks,
> John
>
> On Wednesday, May 27, 2015 at 7:44:18 AM UTC-7, Dieter Wirz wrote:
>>
>> If you only want to send mail, install mutt
>> With mutt u can use any SMTP server, and mutt comes with its own;-)
>>
>> On Tue, May 26, 2015 at 11:09 PM, tcb2  wrote:
>> > I've recently gotten Exim4 to send mail from the BBB with Debian, using
>> > the
>> > Gmail SMTP server. (I tried using the BBB as the server with SMTP port
>> > 25,
>> > but my ISP [Comcast] blocks that port to prevent spam.) I am running
>> > code to
>> > monitor a sensor, and wanted an email alert to me at certain detected
>> > values. Here are the general steps:
>> >
>> > 1. Tell Google that you'll be sending email from your BBB. From a
>> > browser on
>> > the BBB, sign in to your gmail account at:
>> > http://www.google.com/accounts/DisplayUnlockCaptcha
>> >
>> >
>> > 2. Open port 587. For this you need to be root. Check your iptables
>> > (firewall) first to see if 587 is already open:
>> > # iptables -L -n
>> >
>> > If not, then
>> > # iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT
>> >
>> > and, if you don't have any input rules, which is good (see
>> >
>> > http://unix.stackexchange.com/questions/104954/how-to-allow-outgoing-smtp-on-iptables-debian-linux),
>> > then
>> >
>> > # iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>> >
>> > 3. Install and configure exim4 as root. This is the package that sends
>> > the
>> > email.
>> >
>> > # apt-get install exim4
>> >
>> > Now, configure exim as root:
>> >
>> > # dpkg-reconfigure exim4-config
>> > in the dialog, answer as follows:
>> >
>> > Configuration type mail sent by smarthost; received via SMTP or
>> > fetchmail
>> >  System mail name localhost
>> >  IP-addresses to listen on for incoming SMTP connections 127.0.0.1 ; ::1
>> > (to
>> > refuse external connections)
>> > Other destinations for which mail is acceptedleave empty
>> > Machines to relay mail forleave empty
>> > IP address or host name of the outgoing smarthostsmtp.gmail.com::587
>> > Hide local mail name in outgoing mail ?yes
>> > Keep number of DNS-queries minimal (Dial-on-Demand) ?no
>> > Delivery method for local mailmbox format in /var/mail/
>> > Split configuration into small files ?no
>> >
>> > check /etc/exim4/update-exim4.conf.conf to see if the file looks like
>> > the
>> > below, and if not, change it:
>> >
>> > dc_eximconfig_configtype='smarthost'
>> > dc_other_hostnames=''
>> > dc_local_interfaces='127.0.0.1 ; ::1'
>> > dc_readhost=''
>> > dc_relay_domains=''
>> > dc_minimaldns='false'
>> > dc_relay_nets=''
>> > dc_smarthost='smtp.gmail.com::587'
>> > CFILEMODE='644'
>> > dc_use_split_config='false'
>> > dc_hide_mailname='true'
>> > dc_mailname_in_oh='true'
>> > dc_localdelivery='mail_spool'
>> >
>> > Then modify /etc/exim4/passwd.client to (substitute your gmail name and
>> > pwd):
>> >
>> > gmail-smtp.l.google.com:yourgmailn...@gmail.com:yourpassword
>> > *.google.com:yourgmailn...@gmail.com:yourpassword
>> > smtp.gmail.com:youremailna...@gmail.com:yourpassword
>> >
>> > Change permissions, etc
>> >
>> > # chown root:Debian-exim /etc/exim4/passwd.client
>> > # chmod 640 /etc/exim4/passwd.client
>> >
>> > restart Exim
>> >
>> > # update-exim4.conf
>> > # invoke-rc.d exim4 restart
>> >
>> >
>> > 4. Test sending mail
>> >
>> > you can do this in perl, for example:
>> >
>> 

[beagleboard] Beagleboard boot issues

[Rustem Vafin]

Hello.
I have BB rev C3, kingstom mSD 8GB class 10

First, i prepared SD card

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

sudo ./setup_sdcard.sh --mmc /dev/sdb --dtb omap3-beagle


Second, i upgraded uboot
http://elinux.org/BeagleBoardNAND#U-Boot_v2011.12_or_newer

Then i try to boot, booting stop by Load Ramdisk. Help me with booting, 
please.


*Console log:*U-Boot SPL 2016.03-1-g54456ef (Mar 17 2016 - 16:31:02)
Trying to boot from NAND
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!


U-Boot 2016.03-1-g54456ef (Mar 17 2016 - 16:31:02 -0500), Build: 
jenkins-github_Bootloader-Builder-351

OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - bad CRC, using default environment

Beagle Rev C1/C2/C3
Timed out in wait_for_event: status=1000
Check if pads/pull-ups of bus 1 are properly configured
No EEPROM on expansion board
Timed out in wait_for_bb: status=1000
No EEPROM on expansion board
OMAP die ID: 0400d01304013f7937240003
Net:   usb_ether
Error: usb_ether address not set.

Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
Checking for: /uEnv.txt ...
Checking for: /boot/uEnv.txt ...
295 bytes read in 40 ms (6.8 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
Running uname_boot ...
loading /boot/vmlinuz-4.5.0-armv7-x2 ...
5878216 bytes read in 473 ms (11.9 MiB/s)
loading /boot/dtbs/4.5.0-armv7-x2/omap3-beagle.dtb ...
107183 bytes read in 421 ms (248 KiB/s)
loading /boot/initrd.img-4.5.0-armv7-x2 ...
10403546 bytes read in 811 ms (12.2 MiB/s)
debug: [console=ttyO2,115200n8 
root=UUID=26e687b2-0078-49b2-901f-5124edf835c3 ro rootfstype=ext4 rootwait 
musb_hdrc.fifo_mode=5 coherent_pool=1M quiet] ...
debug: [bootz 0x8200 0x8808:9ebeda 0x8800] ...
Kernel image @ 0x8200 [ 0x00 - 0x59b1c8 ]
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Ramdisk to 8f614000, end 8eda ... 

*Environments:*arch=arm
args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} 
root=PARTUUID=${uuid} ro rootfstype=${mmcrootfstype} ${musb} ${cmdline}
args_mmc_old=setenv bootargs console=${console} ${optargs} root=${oldroot} 
ro rootfstype=${mmcrootfstype} ${musb} ${cmdline}
args_mmc_uuid=setenv bootargs console=${console} ${optargs} 
root=UUID=${uuid} ro rootfstype=${mmcrootfstype} ${musb} ${cmdline}
args_netinstall=setenv bootargs ${netinstall_bootargs} ${optargs} 
${cape_disable} ${cape_enable} root=/dev/ram rw ${musb} ${cmdline}
args_uenv_root=setenv bootargs console=${console} ${optargs} 
root=${uenv_root} ro rootfstype=${mmcrootfstype} ${musb} ${cmdline}
baudrate=115200
beaglerev=Cx
board=beagle
board_name=beagle
boot=${interface} dev ${mmcdev}; if ${interface} rescan; then echo SD/MMC 
found on device ${mmcdev};setenv bootpart ${mmcdev}:1; echo Checking for: 
/uEnv.txt ...;if test -e ${interface} ${bootpart} /uEnv.txt; then load 
${interface} ${bootpart} ${loadaddr} /uEnv.txt;env import -t ${loadaddr} 
${filesize};echo Loaded environment from /uEnv.txt;echo Checking if uenvcmd 
is set ...;if test -n ${uenvcmd}; then echo Running uenvcmd ...;run 
uenvcmd;fi;fi; echo Checking for: /boot/uEnv.txt ...;for i in 1 2 3 4 5 6 7 
; do setenv mmcpart ${i};setenv bootpart ${mmcdev}:${mmcpart};if test -e 
${interface} ${bootpart} /boot/uEnv.txt; then load ${interface} ${bootpart} 
${loadaddr} /boot/uEnv.txt;env import -t ${loadaddr} ${filesize};echo 
Loaded environment from /boot/uEnv.txt;if test -n ${dtb}; then setenv 
fdtfile ${dtb};echo Using: dtb=${fdtfile} ...;fi;echo Checking if uname_r 
is set in /boot/uEnv.txt...;if test -n ${uname_r}; then setenv oldroot 
/dev/mmcblk${mmcblk}p${mmcpart};echo Running uname_boot ...;run 
uname_boot;fi;fi;done;fi;
bootcmd=run findfdt; setenv interface mmc; setenv mmcblk 0; setenv mmcdev 
0; run boot;
bootdelay=1
bootdir=/boot
bootenv=uEnv.txt
bootfile=zImage
bootm_size=0x1000
bootpart=0:2
bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${loadaddr}
buddy=none
buddy2=none
console=ttyO2,115200n8
cpu=armv7
ethact=usb_ether
fdt_addr_r=0x8800
fdtaddr=0x8800
fdtfile=undefined
findfdt=if test $beaglerev = AxBx; then setenv fdtfile omap3-beagle.dtb; 
fi; if test $beaglerev = Cx; then setenv fdtfile omap3-beagle.dtb; fi; if 
test $beaglerev = C4; then setenv fdtfile omap3-beagle.dtb; fi; if test 
$beaglerev = xMAB; then setenv fdtfile omap3-beagle-xm-ab.dtb; fi; if test 
$beaglerev = xMC; then setenv fdtfile omap3-beagle-xm.dtb; fi; if test 
$fdtfile = undefined; then echo WARNING: Could not determine device tree to 
use; fi; 
finduuid=part uuid ${interface} ${bootpart} uuid
importbootenv=echo Importing environment from mmc${mmcdev} ...; env import 
-t ${loadaddr} ${filesize}
kernel_addr_r=0x8200
loadaddr=0x8

[beagleboard] Re: Up to 4 axis CNC cape for Beaglebone Black on Kickstarter

[Karl Karpfen]

What is the difference to https://halaser.eu/e1701p.php 
or https://halaser.eu/e1701m.php ?

Am Dienstag, 12. April 2016 23:32:48 UTC+2 schrieb Andy:
>
> Hi,
>
> I like to inform you about a new Kickstarter Project.
> The project will provide an opto coupled CNC cape for the Beaglebone Black.
>
> For more information look at the project page:
>
>
> https://www.kickstarter.com/projects/necitec/up-to-4-axis-beaglebone-black-based-cnc-control?ref=nav_search
>
> Andy
>
>

-- 
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/4ee01a98-557d-44d8-b617-f369beb5bd49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Rick Mann]

> On Apr 20, 2016, at 23:52 , William Hermans  wrote:
> 
> Rick, ah I gotcha now I guess. I'd have to use this -> 
> http://pastebin.com/Wja7ZQRk edit out the edma include line, compile, and 
> then load that up as my dtb= line. Then, perhaps the audio cape will load. It 
> seems as though the McASP stuff has been rewritten since 3.8.x, and the 
> clk_mcasp0 "object" either got renamed, or removed.

Yeah, that's the file that's working for me, EXCEPT: I modified my 
am33xx-overlay-edma-fix.dtsi to comment out the two mcasp entries. If I boot 
with that (on 4.4.7-bone-rt-r9), then I can load the BB-BONE-AUDI-02 overlay, 
and then I can use aplay and speaker-test.

At this point, though, the channels are not quite right. Only the left works. 
This is hopefully due to a very badly configured ALSA.

BTW, your buddy surely didn't use my cape; I've only built one, and it's here. 
:-) The last few days I've been using the CircuitCo AudioCape Rev B (the Rev A 
has a different codec). My cape is almost identical to the Rev B, so I'll soon 
try it again.

> 
> On Wed, Apr 20, 2016 at 11:44 PM, William Hermans  wrote:
> Yeah, right now I'm just trying to get the audio cape to load. The audio cape 
> of our project is actually one of two potential daughter capes, and we're not 
> in a huge hurry to figure all that out. But I figured since you all are doing 
> this, now I'd join in and see if i could help or not. Plus, yes, get our cape 
> working in the process ;)
> 
> Also, my buddy tried one of your capes, and it wound up locking his board up 
> at boot. But the funny thing was, I took his sdcard, and rewrote the dtb= 
> line myself, and the board still would not boot. I had to revert it to an 
> older kernel. So yeah, no idea exactly what was going on. Hard to keep track 
> of what I'm doing, and what he's doing at the same time . . .
> 
> On Wed, Apr 20, 2016 at 10:54 PM, Rick Mann  wrote:
> Er, I guess *this* is the thread on that.
> 
> > On Apr 20, 2016, at 21:39 , William Hermans  wrote:
> >
> > Ah, right, so I'm in the right place ;) I just so happened to fire up the 
> > serial debug port on the remote end
> >
> > [  241.060498] bone_capemgr bone_capemgr: part_number 'BB-BONE-AUDI-02', 
> > version 'N/A'
> > [  241.068352] bone_capemgr bone_capemgr: slot #4: override
> > [  241.073705] bone_capemgr bone_capemgr: Using override eeprom data at 
> > slot 4
> > [  241.081431] bone_capemgr bone_capemgr: slot #4: 'Override Board 
> > Name,00A0,Override Manuf,BB-BONE-AUDI-02'
> > [  241.094660] of_resolve_phandles: Could not find symbol 'clk_mcasp0'
> > [  241.101464] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree
> >
> >
> > On Wed, Apr 20, 2016 at 9:03 PM, William Hermans  wrote:
> > I'm still attempting to get the audio cape overlay to load. Anyone have a 
> > clue as to why it might not work ? Something that did cross my mind is that 
> > perhaps that edma fix include is being included in yet another source file. 
> > Somethign else that is being included.
> >
> > On Wed, Apr 20, 2016 at 8:16 PM, Robert Nelson  
> > wrote:
> >
> >
> > On Wed, Apr 20, 2016 at 8:21 PM, Rafael Vega  wrote:
> >
> >
> > On Wednesday, April 20, 2016 at 3:28:23 PM UTC-5, Rick M wrote:
> > move all the remaining entries that are in the overlay into a new .dts file 
> > based on this <
> > http://pastebin.com/Wja7ZQRk>, compile that, and load it at boot.
> >
> >
> > Here's my attempt to do what you suggest: 
> > https://gist.github.com/rvega/aebb225155b7c8990b3593f3a90851eb
> > It compiles as am335x-boneblack-audio-fixed.dtb without any error messages, 
> > I copied the dtb to /boot/dtbs/4.4.7-bone-rt-r9, added  
> > dtb=am335x-boneblack-audio-fixed.dtb to uEnv.txt and rebooted the board but 
> > when powering up, the 4 user leds stay lit and the heartbeat never starts. 
> > No luck booting.
> >
> > Can anyone spot the error on the dts or suggest a way to get error messages?
> >
> >
> > Yeah, that's very broken..  Here's a quick copy/paste/etc...
> >
> > https://gist.github.com/RobertCNelson/fe8abb7fe11121f0a8c2c0afb291b339
> >
> > I'd say it's 95% there, didn't try building it..
> >
> > 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/CAOCHtYiVST5W%3DXxUFAYjx7oqK64MDPqiKfijadYibztjVRCTPg%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 receiv