Re: [beagleboard] Re: Deleting Device Tree Overlays
Jeremy, thank you; any chance you can field one more (probably not too
intelligent) question as I'm only starting on git?
git clone git://github.com/adafruit/adafruit-beaglebone-io-python
Fatal Python error: Py_Initialize: Unable to get the locale encoding
File /usr/lib/python2.7/encodings/__init__.py, line 123
raise CodecRegistryError,\
^
SyntaxError: invalid syntax
Aborted (core dumped)
I'm guessing I'm doing something stupid? Thanks.
Bit_Pusher
On Monday, December 9, 2013 11:19:20 AM UTC-5, Jeremy L wrote:
On 12/09/2013 08:11 AM, Bit Pusher wrote:
Zach, your suggestions worked. I changed fragment@1 to:
fragment@1 {
target = ocp;
__overlay__ {
test_pru_iomap: pru_iomap {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = mygpio;
status = okay;
};
};
recompiled, and then when I loaded the overlay, and later did ADC.setup(),
I was still able to
control the output pins with the ADC simultaneously working using pru0
commands
SET r30.t14
and
CLR r30.t14
I also added pru0 to:
exclusive-use =
P8.12, pru0;
as you suggested. Finally, your explanations about which files are being
affected when overlays are loaded
was very illuminating. I have spent time googling to try and understand
what is going on with device trees, and
read articles such as http://www.devicetree.org/Device_Tree_Usage, but
your few lines of explanation have been
more useful than anything I have found to date. If there is an article or
site you would recommend to read, I would
be very interested. Also, if you happen to know where the source code for
Adafruit_BBIO.ADC can be found,
I would be interested in trying to follow it through. Once again, thank
you for your
help; with my limited knowledge re device trees, this is not something I
would have
been able to solve on my own.
Bit Pusher
On Friday, December 6, 2013 2:50:39 PM UTC-5, Zachary Thorson wrote:
Odd, dmesg has no errors, but there is definitely a conflict between the
two.
Someone can correct me if I am wrong as this is a guess based on the
behavior of the system (I'll have to look it up later) but loading a device
tree will dynamically map a bunch of hardware register to the file system
in certain locations based on the fragment used. Since the dts file you
posted specified ocp as the target, it placed it into
/sys/devices/ocp.*/[Name].
In this case [Name] is the name that you specified is the one inside of
that __overlay__ keyword. That would be helper.
I know for sure that the Adafruit Library looks for
/sys/devices/ocp.*/helper.* to read from and control the ADC registers, so
if your overlay is overwriting those values, it will lead to problems. I
am not sure why it would affect your pru code without seeing how you are
trying to access the IOs.
Anyway, try changing the line:
test_helper: helper {
to something more unique such as:
pru_iomap {
Recompile, then try loading as before.
Though if you are not using the ocp mapping to write to the IO, you
could probably drop the section. Some of the sample dts files in
/lib/firmware/BB-BONE-PRU-01.dts do not even map the ocp.
Also, you may want to add pru0 to your exclusive use list so another
cape doesn't try to use it at the same time.
After those changes:
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
root@beaglebone:~# echo BB-BONE-PRU $SLOTS
root@beaglebone:~# cat $SLOTS
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU
root@beaglebone:~# python
Python 2.7.3 (default, May 29 2013, 21:25:00)
[GCC 4.7.3 20130205 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
import Adafruit_BBIO.ADC as ADC
ADC.setup()
ADC.read(P9_40)
0.8674950790405
Let me know how it goes,
Zachary Thorson
On Wednesday, December 4, 2013 8:13:14 PM UTC-6, Bit Pusher wrote:
Zach, that would be very good of you; I got if from searching on the net
and it is barely changed (if at all) from what I found (but I didn't record
who I copied it from so I apologize for not giving credit). The *.dts is
below. I might mention that if I load my overlay only, then using cat
$PINS, I can see the expected pin change to 6. If I setup the AD first in
python, I do not see any changes in the $PINS, and if I then try to load my
overlay and check the pins, they are still the same as just after boot.
Bit Pusher
/lib/firmware\ cat BB-BONE-PRU-00A0.dts
/*
* pru dts file
Re: [beagleboard] Re: Deleting Device Tree Overlays
Jeremy, please ignore; sudo apt-get install git-all did the trick.
On Tuesday, December 10, 2013 4:15:18 PM UTC-5, Bit Pusher wrote:
Jeremy, thank you; any chance you can field one more (probably not too
intelligent) question as I'm only starting on git?
git clone git://github.com/adafruit/adafruit-beaglebone-io-python
Fatal Python error: Py_Initialize: Unable to get the locale encoding
File /usr/lib/python2.7/encodings/__init__.py, line 123
raise CodecRegistryError,\
^
SyntaxError: invalid syntax
Aborted (core dumped)
I'm guessing I'm doing something stupid? Thanks.
Bit_Pusher
On Monday, December 9, 2013 11:19:20 AM UTC-5, Jeremy L wrote:
On 12/09/2013 08:11 AM, Bit Pusher wrote:
Zach, your suggestions worked. I changed fragment@1 to:
fragment@1 {
target = ocp;
__overlay__ {
test_pru_iomap: pru_iomap {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = mygpio;
status = okay;
};
};
recompiled, and then when I loaded the overlay, and later did
ADC.setup(), I was still able to
control the output pins with the ADC simultaneously working using pru0
commands
SET r30.t14
and
CLR r30.t14
I also added pru0 to:
exclusive-use =
P8.12, pru0;
as you suggested. Finally, your explanations about which files are being
affected when overlays are loaded
was very illuminating. I have spent time googling to try and understand
what is going on with device trees, and
read articles such as http://www.devicetree.org/Device_Tree_Usage, but
your few lines of explanation have been
more useful than anything I have found to date. If there is an article or
site you would recommend to read, I would
be very interested. Also, if you happen to know where the source code for
Adafruit_BBIO.ADC can be found,
I would be interested in trying to follow it through. Once again, thank
you for your
help; with my limited knowledge re device trees, this is not something I
would have
been able to solve on my own.
Bit Pusher
On Friday, December 6, 2013 2:50:39 PM UTC-5, Zachary Thorson wrote:
Odd, dmesg has no errors, but there is definitely a conflict between the
two.
Someone can correct me if I am wrong as this is a guess based on the
behavior of the system (I'll have to look it up later) but loading a device
tree will dynamically map a bunch of hardware register to the file system
in certain locations based on the fragment used. Since the dts file you
posted specified ocp as the target, it placed it into
/sys/devices/ocp.*/[Name].
In this case [Name] is the name that you specified is the one inside
of that __overlay__ keyword. That would be helper.
I know for sure that the Adafruit Library looks for
/sys/devices/ocp.*/helper.* to read from and control the ADC registers, so
if your overlay is overwriting those values, it will lead to problems. I
am not sure why it would affect your pru code without seeing how you are
trying to access the IOs.
Anyway, try changing the line:
test_helper: helper {
to something more unique such as:
pru_iomap {
Recompile, then try loading as before.
Though if you are not using the ocp mapping to write to the IO, you
could probably drop the section. Some of the sample dts files in
/lib/firmware/BB-BONE-PRU-01.dts do not even map the ocp.
Also, you may want to add pru0 to your exclusive use list so another
cape doesn't try to use it at the same time.
After those changes:
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
root@beaglebone:~# echo BB-BONE-PRU $SLOTS
root@beaglebone:~# cat $SLOTS
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU
root@beaglebone:~# python
Python 2.7.3 (default, May 29 2013, 21:25:00)
[GCC 4.7.3 20130205 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
import Adafruit_BBIO.ADC as ADC
ADC.setup()
ADC.read(P9_40)
0.8674950790405
Let me know how it goes,
Zachary Thorson
On Wednesday, December 4, 2013 8:13:14 PM UTC-6, Bit Pusher wrote:
Zach, that would be very good of you; I got if from searching on the
net and it is barely changed (if at all) from what I found (but I didn't
record who I copied it from so I apologize for not giving credit). The
*.dts is below. I might mention that if I load my overlay only, then using
cat $PINS, I can see the expected pin change to 6. If I setup the AD
first
in python, I do not see any changes in the $PINS, and if I then try to
load
Re: [beagleboard] Re: Deleting Device Tree Overlays
On 12/10/2013 05:45 PM, Bit Pusher wrote:
Jeremy, please ignore; sudo apt-get install git-all did the trick.
On Tuesday, December 10, 2013 4:15:18 PM UTC-5, Bit Pusher wrote:
Jeremy, thank you; any chance you can field one more (probably not
too intelligent) question as I'm only starting on git?
git clone git://github.com/adafruit/adafruit-beaglebone-io-python
http://github.com/adafruit/adafruit-beaglebone-io-python
Fatal Python error: Py_Initialize: Unable to get the locale encoding
File /usr/lib/python2.7/encodings/__init__.py, line 123
raise CodecRegistryError,\
^
SyntaxError: invalid syntax
Aborted (core dumped)
I'm guessing I'm doing something stupid? Thanks.
Bit_Pusher
On Monday, December 9, 2013 11:19:20 AM UTC-5, Jeremy L wrote:
On 12/09/2013 08:11 AM, Bit Pusher wrote:
Zach, your suggestions worked. I changed fragment@1 to:
fragment@1 {
target = ocp;
__overlay__ {
test_pru_iomap: pru_iomap {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = mygpio;
status = okay;
};
};
recompiled, and then when I loaded the overlay, and later did
ADC.setup(), I was still able to
control the output pins with the ADC simultaneously working
using pru0 commands
SETr30.t14
and
CLRr30.t14
I also added pru0 to:
exclusive-use =
P8.12, pru0;
as you suggested. Finally, your explanations about which files
are being affected when overlays are loaded
was very illuminating. I have spent time googling to try and
understand what is going on with device trees, and
read articles such
as http://www.devicetree.org/Device_Tree_Usage
http://www.devicetree.org/Device_Tree_Usage, but your few
lines of explanation have been
more useful than anything I have found to date. If there is an
article or site you would recommend to read, I would
be very interested. Also, if you happen to know where the
source code for Adafruit_BBIO.ADC can be found,
I would be interested in trying to follow it through. Once
again, thank you for your
help; with my limited knowledge re device trees, this is not
something I would have
been able to solve on my own.
Bit Pusher
On Friday, December 6, 2013 2:50:39 PM UTC-5, Zachary Thorson
wrote:
Odd, dmesg has no errors, but there is definitely a
conflict between the two.
Someone can correct me if I am wrong as this is a guess
based on the behavior of the system (I'll have to look it
up later) but loading a device tree will dynamically map a
bunch of hardware register to the file system in certain
locations based on the fragment used. Since the dts file
you posted specified ocp as the target, it placed it into
/sys/devices/ocp.*/[Name].
In this case [Name] is the name that you specified is the
one inside of that __overlay__ keyword. That would be
helper.
I know for sure that the Adafruit Library looks for
/sys/devices/ocp.*/helper.* to read from and control the
ADC registers, so if your overlay is overwriting those
values, it will lead to problems. I am not sure why it
would affect your pru code without seeing how you are
trying to access the IOs.
Anyway, try changing the line:
|
test_helper:helper {
|
to something more unique such as:
|
pru_iomap {
|
Recompile, then try loading as before.
Though if you are not using the ocp mapping to write to
the IO, you could probably drop the section. Some of the
sample dts files in /lib/firmware/BB-BONE-PRU-01.dts do
not even map the ocp.
Also, you may want to add pru0 to your exclusive use
list so another cape doesn't try to use it at the same time.
After those changes:
|
0:54:PF---
1:55:PF---
2:56:PF---
3:57:PF---
4:ff:P-O-L
Bone-LT-eMMC-2G,00A0,TexasInstrument,BB-BONE-EMMC-2G
5:ff:P-O-L
Bone-Black-HDMI,00A0,TexasInstrument,BB-BONELT-HDMI
root@beaglebone:~# echo BB-BONE-PRU $SLOTS
root@beaglebone:~# cat $SLOTS
0:54:PF---
1:55:PF---
2:56:PF---
[beagleboard] Re: Deleting Device Tree Overlays
Zach, your suggestions worked. I changed fragment@1 to:
fragment@1 {
target = ocp;
__overlay__ {
test_pru_iomap: pru_iomap {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = mygpio;
status = okay;
};
};
recompiled, and then when I loaded the overlay, and later did ADC.setup(),
I was still able to
control the output pins with the ADC simultaneously working using pru0
commands
SET r30.t14
and
CLR r30.t14
I also added pru0 to:
exclusive-use =
P8.12, pru0;
as you suggested. Finally, your explanations about which files are being
affected when overlays are loaded
was very illuminating. I have spent time googling to try and understand
what is going on with device trees, and
read articles such as http://www.devicetree.org/Device_Tree_Usage, but your
few lines of explanation have been
more useful than anything I have found to date. If there is an article or
site you would recommend to read, I would
be very interested. Also, if you happen to know where the source code for
Adafruit_BBIO.ADC can be found,
I would be interested in trying to follow it through. Once again, thank you
for your
help; with my limited knowledge re device trees, this is not something I
would have
been able to solve on my own.
Bit Pusher
On Friday, December 6, 2013 2:50:39 PM UTC-5, Zachary Thorson wrote:
Odd, dmesg has no errors, but there is definitely a conflict between the
two.
Someone can correct me if I am wrong as this is a guess based on the
behavior of the system (I'll have to look it up later) but loading a device
tree will dynamically map a bunch of hardware register to the file system
in certain locations based on the fragment used. Since the dts file you
posted specified ocp as the target, it placed it into
/sys/devices/ocp.*/[Name].
In this case [Name] is the name that you specified is the one inside of
that __overlay__ keyword. That would be helper.
I know for sure that the Adafruit Library looks for
/sys/devices/ocp.*/helper.* to read from and control the ADC registers, so
if your overlay is overwriting those values, it will lead to problems. I
am not sure why it would affect your pru code without seeing how you are
trying to access the IOs.
Anyway, try changing the line:
test_helper: helper {
to something more unique such as:
pru_iomap {
Recompile, then try loading as before.
Though if you are not using the ocp mapping to write to the IO, you could
probably drop the section. Some of the sample dts files in
/lib/firmware/BB-BONE-PRU-01.dts do not even map the ocp.
Also, you may want to add pru0 to your exclusive use list so another
cape doesn't try to use it at the same time.
After those changes:
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
root@beaglebone:~# echo BB-BONE-PRU $SLOTS
root@beaglebone:~# cat $SLOTS
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU
root@beaglebone:~# python
Python 2.7.3 (default, May 29 2013, 21:25:00)
[GCC 4.7.3 20130205 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
import Adafruit_BBIO.ADC as ADC
ADC.setup()
ADC.read(P9_40)
0.8674950790405
Let me know how it goes,
Zachary Thorson
On Wednesday, December 4, 2013 8:13:14 PM UTC-6, Bit Pusher wrote:
Zach, that would be very good of you; I got if from searching on the net
and it is barely changed (if at all) from what I found (but I didn't record
who I copied it from so I apologize for not giving credit). The *.dts is
below. I might mention that if I load my overlay only, then using cat
$PINS, I can see the expected pin change to 6. If I setup the AD first in
python, I do not see any changes in the $PINS, and if I then try to load my
overlay and check the pins, they are still the same as just after boot.
Bit Pusher
/lib/firmware\ cat BB-BONE-PRU-00A0.dts
/*
* pru dts file BB-BONE-PRU-00A0.dts
*/
/dts-v1/;
/plugin/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/* identification */
part-number = BB-BONE-PRU;
version = 00A0;
exclusive-use =
P8.12;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
mygpio: pinmux_mygpio{
pinctrl-single,pins =
0x30 0x06
;
};
};
};
fragment@1 {
target = ocp;
__overlay__ {
test_helper: helper {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = mygpio;
status = okay;
};
};
};
fragment@2{
target = pruss;
__overlay__ {
Re: [beagleboard] Re: Deleting Device Tree Overlays
On 12/09/2013 08:11 AM, Bit Pusher wrote:
Zach, your suggestions worked. I changed fragment@1 to:
fragment@1 {
target = ocp;
__overlay__ {
test_pru_iomap: pru_iomap {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = mygpio;
status = okay;
};
};
recompiled, and then when I loaded the overlay, and later did
ADC.setup(), I was still able to
control the output pins with the ADC simultaneously working using pru0
commands
SETr30.t14
and
CLRr30.t14
I also added pru0 to:
exclusive-use =
P8.12, pru0;
as you suggested. Finally, your explanations about which files are
being affected when overlays are loaded
was very illuminating. I have spent time googling to try and
understand what is going on with device trees, and
read articles such as http://www.devicetree.org/Device_Tree_Usage, but
your few lines of explanation have been
more useful than anything I have found to date. If there is an article
or site you would recommend to read, I would
be very interested. Also, if you happen to know where the source code
for Adafruit_BBIO.ADC can be found,
I would be interested in trying to follow it through. Once again,
thank you for your
help; with my limited knowledge re device trees, this is not something
I would have
been able to solve on my own.
Bit Pusher
On Friday, December 6, 2013 2:50:39 PM UTC-5, Zachary Thorson wrote:
Odd, dmesg has no errors, but there is definitely a conflict
between the two.
Someone can correct me if I am wrong as this is a guess based on
the behavior of the system (I'll have to look it up later) but
loading a device tree will dynamically map a bunch of hardware
register to the file system in certain locations based on the
fragment used. Since the dts file you posted specified ocp as the
target, it placed it into /sys/devices/ocp.*/[Name].
In this case [Name] is the name that you specified is the one
inside of that __overlay__ keyword. That would be helper.
I know for sure that the Adafruit Library looks for
/sys/devices/ocp.*/helper.* to read from and control the ADC
registers, so if your overlay is overwriting those values, it will
lead to problems. I am not sure why it would affect your pru code
without seeing how you are trying to access the IOs.
Anyway, try changing the line:
|
test_helper:helper {
|
to something more unique such as:
|
pru_iomap {
|
Recompile, then try loading as before.
Though if you are not using the ocp mapping to write to the IO,
you could probably drop the section. Some of the sample dts files
in /lib/firmware/BB-BONE-PRU-01.dts do not even map the ocp.
Also, you may want to add pru0 to your exclusive use list so
another cape doesn't try to use it at the same time.
After those changes:
|
0:54:PF---
1:55:PF---
2:56:PF---
3:57:PF---
4:ff:P-O-L Bone-LT-eMMC-2G,00A0,TexasInstrument,BB-BONE-EMMC-2G
5:ff:P-O-L Bone-Black-HDMI,00A0,TexasInstrument,BB-BONELT-HDMI
root@beaglebone:~# echo BB-BONE-PRU $SLOTS
root@beaglebone:~# cat $SLOTS
0:54:PF---
1:55:PF---
2:56:PF---
3:57:PF---
4:ff:P-O-L Bone-LT-eMMC-2G,00A0,TexasInstrument,BB-BONE-EMMC-2G
5:ff:P-O-L Bone-Black-HDMI,00A0,TexasInstrument,BB-BONELT-HDMI
7:ff:P-O-L OverrideBoardName,00A0,OverrideManuf,BB-BONE-PRU
root@beaglebone:~# python
Python2.7.3(default,May292013,21:25:00)
[GCC 4.7.320130205(prerelease)]on linux2
Typehelp,copyright,creditsorlicenseformore information.
importAdafruit_BBIO.ADC asADC
ADC.setup()
ADC.read(P9_40)
0.8674950790405
|
Let me know how it goes,
Zachary Thorson
On Wednesday, December 4, 2013 8:13:14 PM UTC-6, Bit Pusher wrote:
Zach, that would be very good of you; I got if from searching
on the net and it is barely changed (if at all) from what I
found (but I didn't record who I copied it from so I apologize
for not giving credit). The *.dts is below. I might mention
that if I load my overlay only, then using cat $PINS, I can
see the expected pin change to 6. If I setup the AD first in
python, I do not see any changes in the $PINS, and if I then
try to load my overlay and check the pins, they are still the
same as just after boot.
Bit Pusher
/lib/firmware\ cat BB-BONE-PRU-00A0.dts
/*
* pru dts file BB-BONE-PRU-00A0.dts
*/
/dts-v1/;
/plugin/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/* identification */
part-number = BB-BONE-PRU;
version = 00A0;
exclusive-use =
P8.12;
fragment@0 {
[beagleboard] Re: Deleting Device Tree Overlays
I'm glad to hear it's working!
Jeremy posted the correct link for the source code. It is written in C
with support for calls through Python.
As far as useful Devicetree links, the Usage one you posted is useful,
though since they write it to be very generic, it can be hard to follow.
A few with a more limited focus (to overlays, specifically the BBB):
Basic Overview of Capes:
https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md
(Ignore
the parts about unloading, it is not functioning)
Excellent More detailed Overview Here:
http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree?view=all
Very well written overlay, good example:
https://github.com/modmaker/BeBoPr/wiki/Device-Tree-Overlay-and-devices
If you learn better by learning why and how rather than just how look here
for an explanation on why they came about and some good explanations:
https://docs.google.com/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub
Zach
On Monday, December 9, 2013 10:11:02 AM UTC-6, Bit Pusher wrote:
Zach, your suggestions worked. I changed fragment@1 to:
fragment@1 {
target = ocp;
__overlay__ {
test_pru_iomap: pru_iomap {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = mygpio;
status = okay;
};
};
recompiled, and then when I loaded the overlay, and later did ADC.setup(),
I was still able to
control the output pins with the ADC simultaneously working using pru0
commands
SET r30.t14
and
CLR r30.t14
I also added pru0 to:
exclusive-use =
P8.12, pru0;
as you suggested. Finally, your explanations about which files are being
affected when overlays are loaded
was very illuminating. I have spent time googling to try and understand
what is going on with device trees, and
read articles such as http://www.devicetree.org/Device_Tree_Usage, but
your few lines of explanation have been
more useful than anything I have found to date. If there is an article or
site you would recommend to read, I would
be very interested. Also, if you happen to know where the source code for
Adafruit_BBIO.ADC can be found,
I would be interested in trying to follow it through. Once again, thank
you for your
help; with my limited knowledge re device trees, this is not something I
would have
been able to solve on my own.
Bit Pusher
On Friday, December 6, 2013 2:50:39 PM UTC-5, Zachary Thorson wrote:
Odd, dmesg has no errors, but there is definitely a conflict between the
two.
Someone can correct me if I am wrong as this is a guess based on the
behavior of the system (I'll have to look it up later) but loading a device
tree will dynamically map a bunch of hardware register to the file system
in certain locations based on the fragment used. Since the dts file you
posted specified ocp as the target, it placed it into
/sys/devices/ocp.*/[Name].
In this case [Name] is the name that you specified is the one inside of
that __overlay__ keyword. That would be helper.
I know for sure that the Adafruit Library looks for
/sys/devices/ocp.*/helper.* to read from and control the ADC registers, so
if your overlay is overwriting those values, it will lead to problems. I
am not sure why it would affect your pru code without seeing how you are
trying to access the IOs.
Anyway, try changing the line:
test_helper: helper {
to something more unique such as:
pru_iomap {
Recompile, then try loading as before.
Though if you are not using the ocp mapping to write to the IO, you could
probably drop the section. Some of the sample dts files in
/lib/firmware/BB-BONE-PRU-01.dts do not even map the ocp.
Also, you may want to add pru0 to your exclusive use list so another
cape doesn't try to use it at the same time.
After those changes:
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
root@beaglebone:~# echo BB-BONE-PRU $SLOTS
root@beaglebone:~# cat $SLOTS
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU
root@beaglebone:~# python
Python 2.7.3 (default, May 29 2013, 21:25:00)
[GCC 4.7.3 20130205 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
import Adafruit_BBIO.ADC as ADC
ADC.setup()
ADC.read(P9_40)
0.8674950790405
Let me know how it goes,
Zachary Thorson
On Wednesday, December 4, 2013 8:13:14 PM UTC-6, Bit Pusher wrote:
Zach, that would be very good of you; I got if from searching on the net
and it is barely changed (if at all) from what I found (but I didn't record
who I copied it from so I apologize
[beagleboard] Re: Deleting Device Tree Overlays
Odd, dmesg has no errors, but there is definitely a conflict between the
two.
Someone can correct me if I am wrong as this is a guess based on the
behavior of the system (I'll have to look it up later) but loading a device
tree will dynamically map a bunch of hardware register to the file system
in certain locations based on the fragment used. Since the dts file you
posted specified ocp as the target, it placed it into
/sys/devices/ocp.*/[Name].
In this case [Name] is the name that you specified is the one inside of
that __overlay__ keyword. That would be helper.
I know for sure that the Adafruit Library looks for
/sys/devices/ocp.*/helper.* to read from and control the ADC registers, so
if your overlay is overwriting those values, it will lead to problems. I
am not sure why it would affect your pru code without seeing how you are
trying to access the IOs.
Anyway, try changing the line:
test_helper: helper {
to something more unique such as:
pru_iomap {
Recompile, then try loading as before.
Though if you are not using the ocp mapping to write to the IO, you could
probably drop the section. Some of the sample dts files in
/lib/firmware/BB-BONE-PRU-01.dts do not even map the ocp.
Also, you may want to add pru0 to your exclusive use list so another cape
doesn't try to use it at the same time.
After those changes:
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
root@beaglebone:~# echo BB-BONE-PRU $SLOTS
root@beaglebone:~# cat $SLOTS
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU
root@beaglebone:~# python
Python 2.7.3 (default, May 29 2013, 21:25:00)
[GCC 4.7.3 20130205 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
import Adafruit_BBIO.ADC as ADC
ADC.setup()
ADC.read(P9_40)
0.8674950790405
Let me know how it goes,
Zachary Thorson
On Wednesday, December 4, 2013 8:13:14 PM UTC-6, Bit Pusher wrote:
Zach, that would be very good of you; I got if from searching on the net
and it is barely changed (if at all) from what I found (but I didn't record
who I copied it from so I apologize for not giving credit). The *.dts is
below. I might mention that if I load my overlay only, then using cat
$PINS, I can see the expected pin change to 6. If I setup the AD first in
python, I do not see any changes in the $PINS, and if I then try to load my
overlay and check the pins, they are still the same as just after boot.
Bit Pusher
/lib/firmware\ cat BB-BONE-PRU-00A0.dts
/*
* pru dts file BB-BONE-PRU-00A0.dts
*/
/dts-v1/;
/plugin/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/* identification */
part-number = BB-BONE-PRU;
version = 00A0;
exclusive-use =
P8.12;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
mygpio: pinmux_mygpio{
pinctrl-single,pins =
0x30 0x06
;
};
};
};
fragment@1 {
target = ocp;
__overlay__ {
test_helper: helper {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = mygpio;
status = okay;
};
};
};
fragment@2{
target = pruss;
__overlay__ {
status = okay;
};
};
};
On Wednesday, December 4, 2013 8:17:47 AM UTC-5, Zachary Thorson wrote:
Could you post or send me your overlay? I can load it on one of my BBBs
and take a look for you.
Zach
On Tuesday, December 3, 2013 8:39:35 PM UTC-6, Bit Pusher wrote:
If I load my device tree overlay to use the high-speed GPIO pins first,
and then try to read the ADC using Adafruit_BBIO, it kicks me out of
python:
~/pru\ sudo python
Python 2.7.5+ (default, Sep 19 2013, 14:17:30)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
import Adafruit_BBIO.ADC as ADC
ADC.setup()
ADC.read(P9_40)
~/pru\
notice no value returned and no python prompt. I suspect this indicates
a problem.
I then rebooted (reset switch), waited until the network started
working again (it takes 5 minutes each time for the network to work,
something needs to timeout)
and then did the same, but this time did not load the device overlay to
change one pru gpio to a high-speed output and got as expected
~/pru\ sudo python
Python 2.7.5+ (default, Sep 19 2013, 14:17:30)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
import Adafruit_BBIO.ADC as ADC
ADC.setup()
ADC.read(P9_40)
0.807471237183
I should mention that when I load both overlays, with my overlay
[beagleboard] Re: Deleting Device Tree Overlays
Could you post or send me your overlay? I can load it on one of my BBBs and take a look for you. Zach On Tuesday, December 3, 2013 8:39:35 PM UTC-6, Bit Pusher wrote: If I load my device tree overlay to use the high-speed GPIO pins first, and then try to read the ADC using Adafruit_BBIO, it kicks me out of python: ~/pru\ sudo python Python 2.7.5+ (default, Sep 19 2013, 14:17:30) [GCC 4.8.1] on linux2 Type help, copyright, credits or license for more information. import Adafruit_BBIO.ADC as ADC ADC.setup() ADC.read(P9_40) ~/pru\ notice no value returned and no python prompt. I suspect this indicates a problem. I then rebooted (reset switch), waited until the network started working again (it takes 5 minutes each time for the network to work, something needs to timeout) and then did the same, but this time did not load the device overlay to change one pru gpio to a high-speed output and got as expected ~/pru\ sudo python Python 2.7.5+ (default, Sep 19 2013, 14:17:30) [GCC 4.8.1] on linux2 Type help, copyright, credits or license for more information. import Adafruit_BBIO.ADC as ADC ADC.setup() ADC.read(P9_40) 0.807471237183 I should mention that when I load both overlays, with my overlay first, cat $SLOTS shows them both there, just the ADC overlay load does not work correctly. If I run the ADC.setup() first, and then run ~/pru\sudo sh -c echo BB-BONE-PRU $SLOTS to load my overlay, then /lib/firmware\ cat $SLOTS 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 7: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-iio 9: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU /lib/firmware\ and both overlays are shown but the high speed pin does not work. Loading just my overlay only, works as expected as far as I can tell (i.e. the led turns on and off). I'm guessing things are not quite as expected. Also, could someone point me to the file in kernel source that loads overlays? Thanks. Bit Pusher On Tuesday, December 3, 2013 12:16:34 PM UTC-5, Zachary Thorson wrote: Correct me if I am wrong, but it appears that you simply want to use ADC and PRU pins whose pins DO NOT physically overlap on the board? The cape-bone-iio device tree only grabs the ADC0-ADC7 pins plus analog power and ground, so it should not interfere with the PRU pins. What issue are you getting when you try to load the PRU overlay after loading the ADC overlay? Note: The adafruit library has a cleanup function in code, but it is commented out due to the lockup on load that you are describing. Zach -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: Deleting Device Tree Overlays
Thanks John, appreciated. Bit Pusher On Tuesday, December 3, 2013 11:45:23 PM UTC-5, John Syne wrote: From: Bit Pusher ken.w@gmail.com javascript: Reply-To: beagl...@googlegroups.com javascript: Date: Tuesday, December 3, 2013 at 6:39 PM To: beagl...@googlegroups.com javascript: Subject: [beagleboard] Re: Deleting Device Tree Overlays If I load my device tree overlay to use the high-speed GPIO pins first, and then try to read the ADC using Adafruit_BBIO, it kicks me out of python: ~/pru\ sudo python Python 2.7.5+ (default, Sep 19 2013, 14:17:30) [GCC 4.8.1] on linux2 Type help, copyright, credits or license for more information. import Adafruit_BBIO.ADC as ADC ADC.setup() ADC.read(P9_40) ~/pru\ notice no value returned and no python prompt. I suspect this indicates a problem. I then rebooted (reset switch), waited until the network started working again (it takes 5 minutes each time for the network to work, something needs to timeout) and then did the same, but this time did not load the device overlay to change one pru gpio to a high-speed output and got as expected ~/pru\ sudo python Python 2.7.5+ (default, Sep 19 2013, 14:17:30) [GCC 4.8.1] on linux2 Type help, copyright, credits or license for more information. import Adafruit_BBIO.ADC as ADC ADC.setup() ADC.read(P9_40) 0.807471237183 I should mention that when I load both overlays, with my overlay first, cat $SLOTS shows them both there, just the ADC overlay load does not work correctly. If I run the ADC.setup() first, and then run ~/pru\sudo sh -c echo BB-BONE-PRU $SLOTS to load my overlay, then /lib/firmware\ cat $SLOTS 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 7: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-iio 9: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU /lib/firmware\ and both overlays are shown but the high speed pin does not work. Loading just my overlay only, works as expected as far as I can tell (i.e. the led turns on and off). I'm guessing things are not quite as expected. Also, could someone point me to the file in kernel source that loads overlays? GIT is your friend and you can use it to find what you want in the kernel. Simply use “git grep capemgr” and it will show you all the files that reference the cape manager, which is what loads and removes overlays. You will notice that there are several patches that attempt to fix crashes related to capemgr. Regards, John Thanks. Bit Pusher On Tuesday, December 3, 2013 12:16:34 PM UTC-5, Zachary Thorson wrote: Correct me if I am wrong, but it appears that you simply want to use ADC and PRU pins whose pins DO NOT physically overlap on the board? The cape-bone-iio device tree only grabs the ADC0-ADC7 pins plus analog power and ground, so it should not interfere with the PRU pins. What issue are you getting when you try to load the PRU overlay after loading the ADC overlay? Note: The adafruit library has a cleanup function in code, but it is commented out due to the lockup on load that you are describing. Zach -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Re: Deleting Device Tree Overlays
Zach, that would be very good of you; I got if from searching on the net
and it is barely changed (if at all) from what I found (but I didn't record
who I copied it from so I apologize for not giving credit). The *.dts is
below. I might mention that if I load my overlay only, then using cat
$PINS, I can see the expected pin change to 6. If I setup the AD first in
python, I do not see any changes in the $PINS, and if I then try to load my
overlay and check the pins, they are still the same as just after boot.
Bit Pusher
/lib/firmware\ cat BB-BONE-PRU-00A0.dts
/*
* pru dts file BB-BONE-PRU-00A0.dts
*/
/dts-v1/;
/plugin/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/* identification */
part-number = BB-BONE-PRU;
version = 00A0;
exclusive-use =
P8.12;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
mygpio: pinmux_mygpio{
pinctrl-single,pins =
0x30 0x06
;
};
};
};
fragment@1 {
target = ocp;
__overlay__ {
test_helper: helper {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = mygpio;
status = okay;
};
};
};
fragment@2{
target = pruss;
__overlay__ {
status = okay;
};
};
};
On Wednesday, December 4, 2013 8:17:47 AM UTC-5, Zachary Thorson wrote:
Could you post or send me your overlay? I can load it on one of my BBBs
and take a look for you.
Zach
On Tuesday, December 3, 2013 8:39:35 PM UTC-6, Bit Pusher wrote:
If I load my device tree overlay to use the high-speed GPIO pins first,
and then try to read the ADC using Adafruit_BBIO, it kicks me out of
python:
~/pru\ sudo python
Python 2.7.5+ (default, Sep 19 2013, 14:17:30)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
import Adafruit_BBIO.ADC as ADC
ADC.setup()
ADC.read(P9_40)
~/pru\
notice no value returned and no python prompt. I suspect this indicates
a problem.
I then rebooted (reset switch), waited until the network started working
again (it takes 5 minutes each time for the network to work, something
needs to timeout)
and then did the same, but this time did not load the device overlay to
change one pru gpio to a high-speed output and got as expected
~/pru\ sudo python
Python 2.7.5+ (default, Sep 19 2013, 14:17:30)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
import Adafruit_BBIO.ADC as ADC
ADC.setup()
ADC.read(P9_40)
0.807471237183
I should mention that when I load both overlays, with my overlay first,
cat $SLOTS shows them both there, just the ADC overlay load does not
work correctly. If I run the ADC.setup() first, and then run
~/pru\sudo sh -c echo BB-BONE-PRU $SLOTS to load my overlay, then
/lib/firmware\ cat $SLOTS
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-iio
9: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU
/lib/firmware\
and both overlays are shown but the high
speed pin does not work.
Loading just my overlay only, works as expected as far as I can tell
(i.e. the led turns on and off).
I'm guessing things are not quite as expected.
Also, could someone point me to the file in kernel source that loads
overlays?
Thanks.
Bit Pusher
On Tuesday, December 3, 2013 12:16:34 PM UTC-5, Zachary Thorson wrote:
Correct me if I am wrong, but it appears that you simply want to use ADC
and PRU pins whose pins DO NOT physically overlap on the board? The
cape-bone-iio device tree only grabs the ADC0-ADC7 pins plus analog power
and ground, so it should not interfere with the PRU pins.
What issue are you getting when you try to load the PRU overlay after
loading the ADC overlay?
Note: The adafruit library has a cleanup function in code, but it is
commented out due to the lockup on load that you are describing.
Zach
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Re: Deleting Device Tree Overlays
Correct me if I am wrong, but it appears that you simply want to use ADC and PRU pins whose pins DO NOT physically overlap on the board? The cape-bone-iio device tree only grabs the ADC0-ADC7 pins plus analog power and ground, so it should not interfere with the PRU pins. What issue are you getting when you try to load the PRU overlay after loading the ADC overlay? Note: The adafruit library has a cleanup function in code, but it is commented out due to the lockup on load that you are describing. Zach -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Re: Deleting Device Tree Overlays
If I load my device tree overlay to use the high-speed GPIO pins first, and then try to read the ADC using Adafruit_BBIO, it kicks me out of python: ~/pru\ sudo python Python 2.7.5+ (default, Sep 19 2013, 14:17:30) [GCC 4.8.1] on linux2 Type help, copyright, credits or license for more information. import Adafruit_BBIO.ADC as ADC ADC.setup() ADC.read(P9_40) ~/pru\ notice no value returned and no python prompt. I suspect this indicates a problem. I then rebooted (reset switch), waited until the network started working again (it takes 5 minutes each time for the network to work, something needs to timeout) and then did the same, but this time did not load the device overlay to change one pru gpio to a high-speed output and got as expected ~/pru\ sudo python Python 2.7.5+ (default, Sep 19 2013, 14:17:30) [GCC 4.8.1] on linux2 Type help, copyright, credits or license for more information. import Adafruit_BBIO.ADC as ADC ADC.setup() ADC.read(P9_40) 0.807471237183 I should mention that when I load both overlays, with my overlay first, cat $SLOTS shows them both there, just the ADC overlay load does not work correctly. If I run the ADC.setup() first, and then run ~/pru\sudo sh -c echo BB-BONE-PRU $SLOTS to load my overlay, then /lib/firmware\ cat $SLOTS 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 7: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-iio 9: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU /lib/firmware\ and both overlays are shown but the high speed pin does not work. Loading just my overlay only, works as expected as far as I can tell (i.e. the led turns on and off). I'm guessing things are not quite as expected. Also, could someone point me to the file in kernel source that loads overlays? Thanks. Bit Pusher On Tuesday, December 3, 2013 12:16:34 PM UTC-5, Zachary Thorson wrote: Correct me if I am wrong, but it appears that you simply want to use ADC and PRU pins whose pins DO NOT physically overlap on the board? The cape-bone-iio device tree only grabs the ADC0-ADC7 pins plus analog power and ground, so it should not interfere with the PRU pins. What issue are you getting when you try to load the PRU overlay after loading the ADC overlay? Note: The adafruit library has a cleanup function in code, but it is commented out due to the lockup on load that you are describing. Zach -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: Deleting Device Tree Overlays
From: Bit Pusher ken.w.mar...@gmail.com Reply-To: beagleboard@googlegroups.com Date: Tuesday, December 3, 2013 at 6:39 PM To: beagleboard@googlegroups.com Subject: [beagleboard] Re: Deleting Device Tree Overlays If I load my device tree overlay to use the high-speed GPIO pins first, and then try to read the ADC using Adafruit_BBIO, it kicks me out of python: ~/pru\ sudo python Python 2.7.5+ (default, Sep 19 2013, 14:17:30) [GCC 4.8.1] on linux2 Type help, copyright, credits or license for more information. import Adafruit_BBIO.ADC as ADC ADC.setup() ADC.read(P9_40) ~/pru\ notice no value returned and no python prompt. I suspect this indicates a problem. I then rebooted (reset switch), waited until the network started working again (it takes 5 minutes each time for the network to work, something needs to timeout) and then did the same, but this time did not load the device overlay to change one pru gpio to a high-speed output and got as expected ~/pru\ sudo python Python 2.7.5+ (default, Sep 19 2013, 14:17:30) [GCC 4.8.1] on linux2 Type help, copyright, credits or license for more information. import Adafruit_BBIO.ADC as ADC ADC.setup() ADC.read(P9_40) 0.807471237183 I should mention that when I load both overlays, with my overlay first, cat $SLOTS shows them both there, just the ADC overlay load does not work correctly. If I run the ADC.setup() first, and then run ~/pru\sudo sh -c echo BB-BONE-PRU $SLOTS to load my overlay, then /lib/firmware\ cat $SLOTS 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 7: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-iio 9: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU /lib/firmware\ and both overlays are shown but the high speed pin does not work. Loading just my overlay only, works as expected as far as I can tell (i.e. the led turns on and off). I'm guessing things are not quite as expected. Also, could someone point me to the file in kernel source that loads overlays? GIT is your friend and you can use it to find what you want in the kernel. Simply use ³git grep capemgr² and it will show you all the files that reference the cape manager, which is what loads and removes overlays. You will notice that there are several patches that attempt to fix crashes related to capemgr. Regards, John Thanks. Bit Pusher On Tuesday, December 3, 2013 12:16:34 PM UTC-5, Zachary Thorson wrote: Correct me if I am wrong, but it appears that you simply want to use ADC and PRU pins whose pins DO NOT physically overlap on the board? The cape-bone-iio device tree only grabs the ADC0-ADC7 pins plus analog power and ground, so it should not interfere with the PRU pins. What issue are you getting when you try to load the PRU overlay after loading the ADC overlay? Note: The adafruit library has a cleanup function in code, but it is commented out due to the lockup on load that you are describing. Zach -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Re: Deleting Device Tree Overlays
if you actually run echo -9 $SLOTS as the root user do you still have this issue? On Sunday, December 1, 2013 7:42:06 PM UTC-6, Bit Pusher wrote: I am trying to use both the A/D and the high-speed PRU direct I/O. I have the A/D working using Adafruit_BBIO.ADC and separately, I can write directly using the PRU based on the TI examples and using a Device Tree Overlay, but have not been successful using them concurrently yet. By using cat /sys/devices/bone_capemgr.9/slots, I found that the commands in python of import Adafruit_BBBIO.ADC as ADC ADCsetup() loaded the cape-bone-iio-00A0.dtbo overlay as /lib/firmware\ cat $SLOTS 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 9: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-iio I then attempted to remove the overlay by /lib/firmware\ sudo sh -c echo -9 $SLOTS /lib/firmware\ cat $SLOTS but the terminal then freezes and never comes back. In another terminal window, using ps aux | grep cat I can see the process, but a kill -9 will not get rid of it. In the other terminal window, I also attempted the cat $SLOTS, and it froze up, as well. The only way of getting it back is rebooting the system. In addition the Adafruit_BBBIO.ADC does not have cleanup function. This behaviour does not seem correct to me. I also tried removing the overlay that set up the PRU output pins, and that did seem to work correctly. Any ideas? Thanks. Bit Pusher -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Re: Deleting Device Tree Overlays
I did a sudo su - and then echo -7 /sys/devices/bone_capemgr.9/slots (as Adafruit_BBIO.ADC had loaded into slot 7). The command appeared to work, but it also dropped me back to my regular user status so something went wrong. When, as a regular user, I cat $SLOTS, it locked up the terminal the same as before. By the way, my kernel is Linux ubuntu-armhf 3.8.13-bone28 On Monday, December 2, 2013 4:10:07 PM UTC-5, btr...@gmail.com wrote: if you actually run echo -9 $SLOTS as the root user do you still have this issue? On Sunday, December 1, 2013 7:42:06 PM UTC-6, Bit Pusher wrote: I am trying to use both the A/D and the high-speed PRU direct I/O. I have the A/D working using Adafruit_BBIO.ADC and separately, I can write directly using the PRU based on the TI examples and using a Device Tree Overlay, but have not been successful using them concurrently yet. By using cat /sys/devices/bone_capemgr.9/slots, I found that the commands in python of import Adafruit_BBBIO.ADC as ADC ADCsetup() loaded the cape-bone-iio-00A0.dtbo overlay as /lib/firmware\ cat $SLOTS 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 9: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-iio I then attempted to remove the overlay by /lib/firmware\ sudo sh -c echo -9 $SLOTS /lib/firmware\ cat $SLOTS but the terminal then freezes and never comes back. In another terminal window, using ps aux | grep cat I can see the process, but a kill -9 will not get rid of it. In the other terminal window, I also attempted the cat $SLOTS, and it froze up, as well. The only way of getting it back is rebooting the system. In addition the Adafruit_BBBIO.ADC does not have cleanup function. This behaviour does not seem correct to me. I also tried removing the overlay that set up the PRU output pins, and that did seem to work correctly. Any ideas? Thanks. Bit Pusher -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: Deleting Device Tree Overlays
As far as I know trying to remove a device tree overlay while the BBB is running the OS will always cause a crash. In order to remove device tree overlays, pass the appropriate parameters to the kernel via uEnv.txt / uboot Such as : optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN Except of course use the device tree overlay name you're trying to unload. However I get the sense you really do not care about this specifically and would possibly like to tweak a device tree overlay file ( make changes etc ) remove and then reload the modified version. Unfortunately I do not think this is possible without a reboot. On Mon, Dec 2, 2013 at 3:57 PM, Bit Pusher ken.w.mar...@gmail.com wrote: I did a sudo su - and then echo -7 /sys/devices/bone_capemgr.9/slots (as Adafruit_BBIO.ADC had loaded into slot 7). The command appeared to work, but it also dropped me back to my regular user status so something went wrong. When, as a regular user, I cat $SLOTS, it locked up the terminal the same as before. By the way, my kernel is Linux ubuntu-armhf 3.8.13-bone28 On Monday, December 2, 2013 4:10:07 PM UTC-5, btr...@gmail.com wrote: if you actually run echo -9 $SLOTS as the root user do you still have this issue? On Sunday, December 1, 2013 7:42:06 PM UTC-6, Bit Pusher wrote: I am trying to use both the A/D and the high-speed PRU direct I/O. I have the A/D working using Adafruit_BBIO.ADC and separately, I can write directly using the PRU based on the TI examples and using a Device Tree Overlay, but have not been successful using them concurrently yet. By using cat /sys/devices/bone_capemgr.9/slots, I found that the commands in python of import Adafruit_BBBIO.ADC as ADC ADCsetup() loaded the cape-bone-iio-00A0.dtbo overlay as /lib/firmware\ cat $SLOTS 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 9: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-iio I then attempted to remove the overlay by /lib/firmware\ sudo sh -c echo -9 $SLOTS /lib/firmware\ cat $SLOTS but the terminal then freezes and never comes back. In another terminal window, using ps aux | grep cat I can see the process, but a kill -9 will not get rid of it. In the other terminal window, I also attempted the cat $SLOTS, and it froze up, as well. The only way of getting it back is rebooting the system. In addition the Adafruit_BBBIO.ADC does not have cleanup function. This behaviour does not seem correct to me. I also tried removing the overlay that set up the PRU output pins, and that did seem to work correctly. Any ideas? Thanks. Bit Pusher -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: Deleting Device Tree Overlays
On 12/2/2013 5:16 PM, William Hermans wrote: However I get the sense you really do not care about this specifically and would possibly like to tweak a device tree overlay file ( make changes etc ) remove and then reload the modified version. Unfortunately I do not think this is possible without a reboot. Like I said...the only way to remove a device tree overlay is to reboot, you can only *ADD* overlays w/o making the system unstable (at best). It sucks^H^H^H is sub-optimal, but that's how it is. The fact that loading an overlay works pretty well is pretty convenient, and downright amazing, when you consider what the underlying device tree was intended to support. It sure beats rebooting *AND* having to edit your board.dto file! :) -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: Deleting Device Tree Overlays
Charles, where do you get your information from ? Not trying to be rude or condescending, or anything of that nature. I only ask because I have actual hands experience with this feature and have often wondered if there could be a potential work around( through code ). On Mon, Dec 2, 2013 at 4:33 PM, Charles Steinkuehler char...@steinkuehler.net wrote: On 12/2/2013 5:16 PM, William Hermans wrote: However I get the sense you really do not care about this specifically and would possibly like to tweak a device tree overlay file ( make changes etc ) remove and then reload the modified version. Unfortunately I do not think this is possible without a reboot. Like I said...the only way to remove a device tree overlay is to reboot, you can only *ADD* overlays w/o making the system unstable (at best). It sucks^H^H^H is sub-optimal, but that's how it is. The fact that loading an overlay works pretty well is pretty convenient, and downright amazing, when you consider what the underlying device tree was intended to support. It sure beats rebooting *AND* having to edit your board.dto file! :) -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: Deleting Device Tree Overlays
On 12/2/2013 5:48 PM, William Hermans wrote: Charles, where do you get your information from ? Not trying to be rude or condescending, or anything of that nature. I only ask because I have actual hands experience with this feature and have often wondered if there could be a potential work around( through code ). My experience is mostly from beating my head against the wall trying to get this working, along with crawling through some of the device tree back-story, technical details, and kernel code. Basically, device tree is intended to be a *STATIC* definition of the machine hardware available to the kernel at boot. Pretty much *ALL* device tree does is store a bunch of values that can be retrieved via an identifier (think INI file and you're not too far off). The overlay stuff is all pretty much BeagleBone specific. Loading an overlay works fairly well because it is very similar in concept and process to the kernel initialization...various kernel module code gets run and other kernel modules may or may not already be present or fully loaded. If your driver code can't deal with this, it's going to be buggy in general use, regardless of whether or not you're trying to load overlays. In a sense, loading a device tree overlay is very much like simply extending system initialization for what could be a _long_ time while a bunch of other code runs. :) Unloading an overlay, however, is a minefield of potential problems, particularly since most of the ARM drivers weren't written with hot-plug in mind. I'm not even sure most of the drivers can be unloaded at the kernel level (hmm...I should go off and try to rmmod some of them). Anyway, true hotplug is a big-fat-hairy-can-of-worms, and pretty much _none_ of the ARM ecosystem has been written with hot-plug in mind (except for the bits that carry over from other systems, like USB and PCI). It's not really surprising it crashes, it's just kind of annoying. :) As for a work-around, I believe the saying goes: There is no problem in computer science which cannot be solved by one more level of indirection. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: Deleting Device Tree Overlays
In all honesty, there really should be no hotplug anyhow. At not for this sort of thing. The device should be powered down when wiring new circuitry to it anyhow right ? On Mon, Dec 2, 2013 at 5:15 PM, Charles Steinkuehler char...@steinkuehler.net wrote: On 12/2/2013 5:48 PM, William Hermans wrote: Charles, where do you get your information from ? Not trying to be rude or condescending, or anything of that nature. I only ask because I have actual hands experience with this feature and have often wondered if there could be a potential work around( through code ). My experience is mostly from beating my head against the wall trying to get this working, along with crawling through some of the device tree back-story, technical details, and kernel code. Basically, device tree is intended to be a *STATIC* definition of the machine hardware available to the kernel at boot. Pretty much *ALL* device tree does is store a bunch of values that can be retrieved via an identifier (think INI file and you're not too far off). The overlay stuff is all pretty much BeagleBone specific. Loading an overlay works fairly well because it is very similar in concept and process to the kernel initialization...various kernel module code gets run and other kernel modules may or may not already be present or fully loaded. If your driver code can't deal with this, it's going to be buggy in general use, regardless of whether or not you're trying to load overlays. In a sense, loading a device tree overlay is very much like simply extending system initialization for what could be a _long_ time while a bunch of other code runs. :) Unloading an overlay, however, is a minefield of potential problems, particularly since most of the ARM drivers weren't written with hot-plug in mind. I'm not even sure most of the drivers can be unloaded at the kernel level (hmm...I should go off and try to rmmod some of them). Anyway, true hotplug is a big-fat-hairy-can-of-worms, and pretty much _none_ of the ARM ecosystem has been written with hot-plug in mind (except for the bits that carry over from other systems, like USB and PCI). It's not really surprising it crashes, it's just kind of annoying. :) As for a work-around, I believe the saying goes: There is no problem in computer science which cannot be solved by one more level of indirection. -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
