Discussion:
Could BB-BONELT-BT-00A0.dtbo have an error?
(too old to reply)
Bit Pusher
2014-03-12 16:24:05 UTC
Permalink
BBB Ubuntu 3.8.13-bone28 cross compiled from Robert Nelson's source

I have been trying to use P9-25 as a GPIO output (gpio3_21), but couldn't
change it's mode. I tried to do this with an overlay file and got the error
message (in dmesg)

[177534.038798] bone-capemgr bone_capemgr.9: slot #10: generic override
[177534.038816] bone-capemgr bone_capemgr.9: bone: Using override eeprom
data at slot 10
[177534.038834] bone-capemgr bone_capemgr.9: slot #10: 'Override Board
Name,00A0,Override Manuf,cape-bone-pru'
[177534.040746] bone-capemgr bone_capemgr.9: slot #10: Requesting part
number/version based 'cape-bone-pru-00A0.dtbo
[177534.040775] bone-capemgr bone_capemgr.9: slot #10: Requesting firmware
'cape-bone-pru-00A0.dtbo' for board-name 'Override Board Name', version
'00A0'
[177534.041685] bone-capemgr bone_capemgr.9: slot #10: dtbo
'cape-bone-pru-00A0.dtbo' loaded; converting to live tree
[177534.041964] bone-capemgr bone_capemgr.9: slot #10: cape-bone-pru
conflict P9.25 (#5:BB-BONELT-HDMI)
[177534.051650] bone-capemgr bone_capemgr.9: slot #10: Failed verification

But from the BBB technical reference P9.25 is not one of the HDMI reserved
pins. My guess (after lots of looking around etc.) is the HDMI is loaded by
the following lines in
am335x-boneblack.dts (after uncompiling from *.dtb) in /boot/dtbs:

***@101 {
ti,cape-override;
priority = <0x1>;
compatible = "ti,beaglebone-black";
board-name = "Bone-Black-HDMI";
version = "00A0";
manufacturer = "Texas Instruments";
part-number = "BB-BONELT-HDMI";
};

My guess? is this loads an appropriate *.dtbo /lib/firmware that has a line:
part-number = "BB-BONELT-HDMI";
in the header section of it's */dts file; could someone confirm my
understanding here?

Going to /lib/firmware I ran >grep -i BB-BONELT-HDMI *
and found the canditates:
Binary file cape-boneblack-hdmi-00A0.dtbo matches
Binary file cape-boneblack-hdmin-00A0.dtbo matches

In the file cape-boneblack-hdmi-00A0.dts (after un-compiling) are the lines:

exclusive-use = "P9.25", "P9.28", "P9.29", "P9.31", "P8.45",
"P8.46", "P8.43", "P8.44", "P8.41", "P8.42", "P8.39", "P8.40", "P8.37",
"P8.38", "P8.36", "P8.34", "P8.35", "P8.33", "P8.31", "P8.32", "P8.27",
"P8.29", "P8.28", "P8.30", "gpio1_27", "mcasp0", "lcd";

***@0 {
target = <0xdeadbeef>;

__overlay__ {

nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <0x1b0 0x3 0xa0 0x8
0xa4 0x8 0xa8 0x8 0xac 0x8 0xb0 0x8 0xb4 0x8 0xb8 0x8 0xbc 0x8 0xc0 0x8
0xc4 0x8 0xc8 0x8 0xcc 0x8 0xd0 0x8 0xd4 0x8 0xd8 0x8 0xdc 0x8 0xe0 0x0
0xe4 0x0 0xe8 0x0 0xec 0x0>;
linux,phandle = <0x1>;
phandle = <0x1>;
};

It appears to me that the pinctrl-single,pins do correspond to Table 13 in
section 7.10.1 of the BeagleBone Black System Reference Manual, but there
appears to be too many
values for exclusive-use, and that these values do not correspond to
the pinctrl-single,pins values. In particular there should not be any
header pins from P9, and I also do understand why
"gpio1_27", "mcasp0", "lcd" are included. Indeed, gpio1_27 is not even a
possibility for the headers. (I'm also wondering why pinctrl-single,pins
appear to be a random order?).
After backing up cape-boneblack-hdmi-00A0.dts, I edited it take
out "P9.25", "P9.28", "P9.29", "P9.31" from exclusive-use, and then
re-compiled using:
sudo sh -c "dtc -@ -O dtb -o cape-boneblack-hdmi-00A0.dtbo
cape-boneblack-hdmi-00A0.dts"
After re-booting (and waiting 5 minutes before I could ssh in - I sure wish
I could fix this and/or get the usb-ether working), I then loaded the
overlay again, but I still had the conflict

/lib/firmware\> dmesg | tail -2
[ 196.851263] bone-capemgr bone_capemgr.9: slot #7: cape-bone-pru conflict
P9.25 (#5:BB-BONELT-HDMI)
[ 196.860761] bone-capemgr bone_capemgr.9: slot #7: Failed verification
/lib/firmware\>

It looks like my guess on where the exclusive-use is loaded from is
incorrect. Any suggestions on what to try next? Is it necessary to
recompile the kernel to change the exclusive-use
pins determined at boot? If so, any links to help with this? 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Gerald Coley
2014-03-12 16:35:34 UTC
Permalink
From the schematic you can see that thi spin is used as th eclock input for
the HDMI. Please read the note.

Gerald
:



[image: Inline image 1]
BBB Ubuntu 3.8.13-bone28 cross compiled from Robert Nelson's source
I have been trying to use P9-25 as a GPIO output (gpio3_21), but couldn't
change it's mode. I tried to do this with an overlay file and got the error
message (in dmesg)
[177534.038798] bone-capemgr bone_capemgr.9: slot #10: generic override
[177534.038816] bone-capemgr bone_capemgr.9: bone: Using override eeprom
data at slot 10
[177534.038834] bone-capemgr bone_capemgr.9: slot #10: 'Override Board
Name,00A0,Override Manuf,cape-bone-pru'
[177534.040746] bone-capemgr bone_capemgr.9: slot #10: Requesting part
number/version based 'cape-bone-pru-00A0.dtbo
[177534.040775] bone-capemgr bone_capemgr.9: slot #10: Requesting firmware
'cape-bone-pru-00A0.dtbo' for board-name 'Override Board Name', version
'00A0'
[177534.041685] bone-capemgr bone_capemgr.9: slot #10: dtbo
'cape-bone-pru-00A0.dtbo' loaded; converting to live tree
[177534.041964] bone-capemgr bone_capemgr.9: slot #10: cape-bone-pru
conflict P9.25 (#5:BB-BONELT-HDMI)
[177534.051650] bone-capemgr bone_capemgr.9: slot #10: Failed verification
But from the BBB technical reference P9.25 is not one of the HDMI reserved
pins. My guess (after lots of looking around etc.) is the HDMI is loaded by
the following lines in
ti,cape-override;
priority = <0x1>;
compatible = "ti,beaglebone-black";
board-name = "Bone-Black-HDMI";
version = "00A0";
manufacturer = "Texas Instruments";
part-number = "BB-BONELT-HDMI";
};
part-number = "BB-BONELT-HDMI";
in the header section of it's */dts file; could someone confirm my
understanding here?
Going to /lib/firmware I ran >grep -i BB-BONELT-HDMI *
Binary file cape-boneblack-hdmi-00A0.dtbo matches
Binary file cape-boneblack-hdmin-00A0.dtbo matches
exclusive-use = "P9.25", "P9.28", "P9.29", "P9.31", "P8.45",
"P8.46", "P8.43", "P8.44", "P8.41", "P8.42", "P8.39", "P8.40", "P8.37",
"P8.38", "P8.36", "P8.34", "P8.35", "P8.33", "P8.31", "P8.32", "P8.27",
"P8.29", "P8.28", "P8.30", "gpio1_27", "mcasp0", "lcd";
target = <0xdeadbeef>;
__overlay__ {
nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <0x1b0 0x3 0xa0 0x8
0xa4 0x8 0xa8 0x8 0xac 0x8 0xb0 0x8 0xb4 0x8 0xb8 0x8 0xbc 0x8 0xc0 0x8
0xc4 0x8 0xc8 0x8 0xcc 0x8 0xd0 0x8 0xd4 0x8 0xd8 0x8 0xdc 0x8 0xe0 0x0
0xe4 0x0 0xe8 0x0 0xec 0x0>;
linux,phandle = <0x1>;
phandle = <0x1>;
};
It appears to me that the pinctrl-single,pins do correspond to Table 13 in
section 7.10.1 of the BeagleBone Black System Reference Manual, but there
appears to be too many
values for exclusive-use, and that these values do not correspond to
the pinctrl-single,pins values. In particular there should not be any
header pins from P9, and I also do understand why
"gpio1_27", "mcasp0", "lcd" are included. Indeed, gpio1_27 is not even a
possibility for the headers. (I'm also wondering why pinctrl-single,pins
appear to be a random order?).
After backing up cape-boneblack-hdmi-00A0.dts, I edited it take
out "P9.25", "P9.28", "P9.29", "P9.31" from exclusive-use, and then
cape-boneblack-hdmi-00A0.dts"
After re-booting (and waiting 5 minutes before I could ssh in - I sure
wish I could fix this and/or get the usb-ether working), I then loaded the
overlay again, but I still had the conflict
/lib/firmware\> dmesg | tail -2
[ 196.851263] bone-capemgr bone_capemgr.9: slot #7: cape-bone-pru
conflict P9.25 (#5:BB-BONELT-HDMI)
[ 196.860761] bone-capemgr bone_capemgr.9: slot #7: Failed verification
/lib/firmware\>
It looks like my guess on where the exclusive-use is loaded from is
incorrect. Any suggestions on what to try next? Is it necessary to
recompile the kernel to change the exclusive-use
pins determined at boot? If so, any links to help with this? 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
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Kenneth Martin
2014-03-12 17:11:45 UTC
Permalink
Thanks Gerald, but isn't this a clock for McASP0 which is a
multi-channel audio block and according the BBB reference manual not
loaded by default? Shouldn't it still be possible to change the Pin mux
assuming the McASP0 is not needed? Thanks again.
-Ken
From the schematic you can see that thi spin is used as th eclock
input for the HDMI. Please read the note.
Gerald
Inline image 1
BBB Ubuntu 3.8.13-bone28 cross compiled from Robert Nelson's source
I have been trying to use P9-25 as a GPIO output (gpio3_21), but
couldn't change it's mode. I tried to do this with an overlay file
and got the error message (in dmesg)
[177534.038798] bone-capemgr bone_capemgr.9: slot #10: generic override
[177534.038816] bone-capemgr bone_capemgr.9: bone: Using override
eeprom data at slot 10
[177534.038834] bone-capemgr bone_capemgr.9: slot #10: 'Override
Board Name,00A0,Override Manuf,cape-bone-pru'
[177534.040746] bone-capemgr bone_capemgr.9: slot #10: Requesting
part number/version based 'cape-bone-pru-00A0.dtbo
[177534.040775] bone-capemgr bone_capemgr.9: slot #10: Requesting
firmware 'cape-bone-pru-00A0.dtbo' for board-name 'Override Board
Name', version '00A0'
[177534.041685] bone-capemgr bone_capemgr.9: slot #10: dtbo
'cape-bone-pru-00A0.dtbo' loaded; converting to live tree
cape-bone-pru conflict P9.25 (#5:BB-BONELT-HDMI)
[177534.051650] bone-capemgr bone_capemgr.9: slot #10: Failed verification
But from the BBB technical reference P9.25 is not one of the HDMI
reserved pins. My guess (after lots of looking around etc.) is the
HDMI is loaded by the following lines in
ti,cape-override;
priority = <0x1>;
compatible = "ti,beaglebone-black";
board-name = "Bone-Black-HDMI";
version = "00A0";
manufacturer = "Texas Instruments";
part-number = "BB-BONELT-HDMI";
};
part-number = "BB-BONELT-HDMI";
in the header section of it's */dts file; could someone confirm my
understanding here?
Going to /lib/firmware I ran >grep -i BB-BONELT-HDMI *
Binary file cape-boneblack-hdmi-00A0.dtbo matches
Binary file cape-boneblack-hdmin-00A0.dtbo matches
exclusive-use = "P9.25", "P9.28", "P9.29", "P9.31",
"P8.45", "P8.46", "P8.43", "P8.44", "P8.41", "P8.42", "P8.39",
"P8.40", "P8.37", "P8.38", "P8.36", "P8.34", "P8.35", "P8.33",
"P8.31", "P8.32", "P8.27", "P8.29", "P8.28", "P8.30", "gpio1_27",
"mcasp0", "lcd";
target = <0xdeadbeef>;
__overlay__ {
nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <0x1b0 0x3
0xa0 0x8 0xa4 0x8 0xa8 0x8 0xac 0x8 0xb0 0x8 0xb4 0x8 0xb8 0x8
0xbc 0x8 0xc0 0x8 0xc4 0x8 0xc8 0x8 0xcc 0x8 0xd0 0x8 0xd4 0x8
0xd8 0x8 0xdc 0x8 0xe0 0x0 0xe4 0x0 0xe8 0x0 0xec 0x0>;
linux,phandle = <0x1>;
phandle = <0x1>;
};
It appears to me that the pinctrl-single,pins do correspond to
Table 13 in section 7.10.1 of the BeagleBone Black System
Reference Manual, but there appears to be too many
values for exclusive-use, and that these values do not correspond
to the pinctrl-single,pins values. In particular there should not
be any header pins from P9, and I also do understand why
"gpio1_27", "mcasp0", "lcd" are included. Indeed, gpio1_27 is not
even a possibility for the headers. (I'm also wondering
why pinctrl-single,pins appear to be a random order?).
After backing up cape-boneblack-hdmi-00A0.dts, I edited it take
out "P9.25", "P9.28", "P9.29", "P9.31" from exclusive-use, and
cape-boneblack-hdmi-00A0.dts"
After re-booting (and waiting 5 minutes before I could ssh in - I
sure wish I could fix this and/or get the usb-ether working), I
then loaded the overlay again, but I still had the conflict
/lib/firmware\> dmesg | tail -2
[ 196.851263] bone-capemgr bone_capemgr.9: slot #7: cape-bone-pru
conflict P9.25 (#5:BB-BONELT-HDMI)
[ 196.860761] bone-capemgr bone_capemgr.9: slot #7: Failed verification
/lib/firmware\>
It looks like my guess on where the exclusive-use is loaded from
is incorrect. Any suggestions on what to try next? Is it necessary
to recompile the kernel to change the exclusive-use
pins determined at boot? If so, any links to help with this? 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,
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 a topic in the
Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/beagleboard/g2DC1GeybSE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Robert Nelson
2014-03-12 16:37:18 UTC
Permalink
Post by Bit Pusher
BBB Ubuntu 3.8.13-bone28 cross compiled from Robert Nelson's source
"bone28" that's like from 6 months ago:

https://github.com/RobertCNelson/linux-dev/commits/am33x-v3.8

Regards,
--
Robert Nelson
http://www.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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Kenneth Martin
2014-03-12 17:16:25 UTC
Permalink
Yes, Robert; the last time I upgraded to bone28, it took considerably
over a week to get all my software re-installed and working. For this
reason, I don't upgrade continually, or I will be spending all my time
upgrading and won't have any time left for development. In my
experience, every upgrade fixes some things and breaks other things, so
one can't do them continuously. I think this is reason for 'long-term
stable' versus development versions? If I do take on upgrading to the
most recent version, do you know if this problem has been fixed or is it
still present? Thanks again.
-Ken
Post by Robert Nelson
Post by Bit Pusher
BBB Ubuntu 3.8.13-bone28 cross compiled from Robert Nelson's source
https://github.com/RobertCNelson/linux-dev/commits/am33x-v3.8
Regards,
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Gerald Coley
2014-03-12 17:35:07 UTC
Permalink
It is loaded by default. It is the clock for the HDMI Audio. From a HW
standpoint to use that pin as a GPIO pin, you have to disable the clock
oscillator and reconfigure the pin usage for GPIO. From a SW standpoint
you may have to disconnect the HDMI. Not sure if Audio can be
killed separately or not..

Gerald
Yes, Robert; the last time I upgraded to bone28, it took considerably over
a week to get all my software re-installed and working. For this reason, I
don't upgrade continually, or I will be spending all my time upgrading and
won't have any time left for development. In my experience, every upgrade
fixes some things and breaks other things, so one can't do them
continuously. I think this is reason for 'long-term stable' versus
development versions? If I do take on upgrading to the most recent version,
do you know if this problem has been fixed or is it still present? Thanks
again.
-Ken
Post by Robert Nelson
Post by Bit Pusher
BBB Ubuntu 3.8.13-bone28 cross compiled from Robert Nelson's source
https://github.com/RobertCNelson/linux-dev/commits/am33x-v3.8
Regards,
--
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
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
John Syn
2014-03-12 18:21:43 UTC
Permalink
From: Gerald Coley <gerald-hcmAuCOw+vXj4SYmN/***@public.gmane.org>
Reply-To: <beagleboard-/***@public.gmane.org>
Date: Wednesday, March 12, 2014 at 10:35 AM
To: "beagleboard-/***@public.gmane.org" <beagleboard-/***@public.gmane.org>
Cc: Ken Martin <martin-TxPoQvD3IN4C6LszWs/***@public.gmane.org>
Subject: Re: [beagleboard] Could BB-BONELT-BT-00A0.dtbo have an error?
Post by Gerald Coley
It is loaded by default. It is the clock for the HDMI Audio. From a HW
standpoint to use that pin as a GPIO pin, you have to disable the clock
oscillator and reconfigure the pin usage for GPIO. From a SW standpoint you
may have to disconnect the HDMI. Not sure if Audio can be killed separately or
not..
If you want HDMI, but not HDMI Audio, disable the HDMI device three (which
includes HDMI Audio) and leave the HDMIN (which includes HDMI without Audio)
enabled. Do something like this in uEnv.txt
optargs=capemgr.disable_partno=BB-BONELT-HDMI

Regards,
John
Post by Gerald Coley
Gerald
Yes, Robert; the last time I upgraded to bone28, it took considerably over a
week to get all my software re-installed and working. For this reason, I
don't upgrade continually, or I will be spending all my time upgrading and
won't have any time left for development. In my experience, every upgrade
fixes some things and breaks other things, so one can't do them continuously.
I think this is reason for 'long-term stable' versus development versions? If
I do take on upgrading to the most recent version, do you know if this
problem has been fixed or is it still present? Thanks again.
-Ken
Post by Robert Nelson
Post by Bit Pusher
BBB Ubuntu 3.8.13-bone28 cross compiled from Robert Nelson's source
https://github.com/RobertCNelson/linux-dev/commits/am33x-v3.8
<https://github.com/RobertCNelson/linux-dev/commits/am33x-v3.8>
Regards,
--
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
For more options, visit https://groups.google.com/d/optout
<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
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Bit Pusher
2014-03-12 21:05:10 UTC
Permalink
Thanks John, this worked. I also tried modifying
/lib/firmware/cape-boneblack-hdmi-00A0.dts to remove the conflicts (without
disabling HDMI in /boot/uboot/uEnv.txt) , and then recompiled to make a new
/lib/firmware/cape-boneblack-hdmi-00A0.dtbo,
but dmesg still reported a conflict with P9_25 even though P9_25 and mcasp0
had been removed. This indicates to me
that /lib/firmware/cape-boneblack-hdmi-00A0.dtbo is not being read from
/lib/firmware at boot; do you know where it is being read from? Or can you
point me to a link for the process and places of loading overlay files on
the Ubuntu BBB at boot? I am really having difficulties finding
documentation regarding this so any helpful links are appreciated.
Date: Wednesday, March 12, 2014 at 10:35 AM
Subject: Re: [beagleboard] Could BB-BONELT-BT-00A0.dtbo have an error?
It is loaded by default. It is the clock for the HDMI Audio. From a HW
standpoint to use that pin as a GPIO pin, you have to disable the clock
oscillator and reconfigure the pin usage for GPIO. From a SW standpoint
you may have to disconnect the HDMI. Not sure if Audio can be
killed separately or not..
If you want HDMI, but not HDMI Audio, disable the HDMI device three (which
includes HDMI Audio) and leave the HDMIN (which includes HDMI without
Audio) enabled. Do something like this in uEnv.txt
optargs=capemgr.disable_partno=BB-BONELT-HDMI
Regards,
John
Gerald
Post by Kenneth Martin
Yes, Robert; the last time I upgraded to bone28, it took considerably
over a week to get all my software re-installed and working. For this
reason, I don't upgrade continually, or I will be spending all my time
upgrading and won't have any time left for development. In my experience,
every upgrade fixes some things and breaks other things, so one can't do
them continuously. I think this is reason for 'long-term stable' versus
development versions? If I do take on upgrading to the most recent version,
do you know if this problem has been fixed or is it still present? Thanks
again.
-Ken
Post by Robert Nelson
Post by Bit Pusher
BBB Ubuntu 3.8.13-bone28 cross compiled from Robert Nelson's source
https://github.com/RobertCNelson/linux-dev/commits/am33x-v3.8
Regards,
--
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
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
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Robert Nelson
2014-03-12 21:09:56 UTC
Permalink
Post by Bit Pusher
Thanks John, this worked. I also tried modifying
/lib/firmware/cape-boneblack-hdmi-00A0.dts to remove the conflicts (without
disabling HDMI in /boot/uboot/uEnv.txt) , and then recompiled to make a new
/lib/firmware/cape-boneblack-hdmi-00A0.dtbo,
but dmesg still reported a conflict with P9_25 even though P9_25 and mcasp0
had been removed. This indicates to me that
/lib/firmware/cape-boneblack-hdmi-00A0.dtbo is not being read from
/lib/firmware at boot; do you know where it is being read from? Or can you
point me to a link for the process and places of loading overlay files on
the Ubuntu BBB at boot? I am really having difficulties finding
documentation regarding this so any helpful links are appreciated.
With the current kernel config, all "firmware" is built into the
kernel. We could disable that, but then it could take udev up to 60
seconds to actually find it on debian/ubuntu based systems. Best
thing to do is disable all the capes in uEnv.txt then write an init
script to load that specific *.dtbo into the slot early in bootup.

Regards,
--
Robert Nelson
http://www.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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Robert Nelson
2014-03-12 21:15:01 UTC
Permalink
Post by Robert Nelson
Post by Bit Pusher
Thanks John, this worked. I also tried modifying
/lib/firmware/cape-boneblack-hdmi-00A0.dts to remove the conflicts (without
disabling HDMI in /boot/uboot/uEnv.txt) , and then recompiled to make a new
/lib/firmware/cape-boneblack-hdmi-00A0.dtbo,
but dmesg still reported a conflict with P9_25 even though P9_25 and mcasp0
had been removed. This indicates to me that
/lib/firmware/cape-boneblack-hdmi-00A0.dtbo is not being read from
/lib/firmware at boot; do you know where it is being read from? Or can you
point me to a link for the process and places of loading overlay files on
the Ubuntu BBB at boot? I am really having difficulties finding
documentation regarding this so any helpful links are appreciated.
With the current kernel config, all "firmware" is built into the
kernel. We could disable that, but then it could take udev up to 60
seconds to actually find it on debian/ubuntu based systems. Best
thing to do is disable all the capes in uEnv.txt then write an init
script to load that specific *.dtbo into the slot early in bootup.
for reference, something like:

https://github.com/RobertCNelson/omap-image-builder/blob/master/target/init_scripts/capemgr-ubuntu.sh

Regards,
--
Robert Nelson
http://www.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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Bit Pusher
2014-03-12 21:58:49 UTC
Permalink
Robert once again thanks. In your script:

start on runlevel 2
script
if test -f /etc/default/capemgr; then
. /etc/default/capemgr
fi
capemgr=$(ls /sys/devices/bone_capemgr.*/slots 2> /dev/null || true)
if [ ! "x${CAPE}" = "x" ] ; then
if [ ! "x${capemgr}" = "x" ] ; then
echo ${CAPE} > ${capemgr}
fi
fi
end script


I believe "capemgr=$(ls /sys/devices/bone_capemgr.*/slots 2> /dev/null ||
true)" is to resolve whether it is bone_capemgr.8 or .9
but I can not figure out how ${CAPE} is set? Thanks again.
Post by Bit Pusher
Post by Robert Nelson
Post by Bit Pusher
Thanks John, this worked. I also tried modifying
/lib/firmware/cape-boneblack-hdmi-00A0.dts to remove the conflicts
(without
Post by Robert Nelson
Post by Bit Pusher
disabling HDMI in /boot/uboot/uEnv.txt) , and then recompiled to make a
new
Post by Robert Nelson
Post by Bit Pusher
/lib/firmware/cape-boneblack-hdmi-00A0.dtbo,
but dmesg still reported a conflict with P9_25 even though P9_25 and
mcasp0
Post by Robert Nelson
Post by Bit Pusher
had been removed. This indicates to me that
/lib/firmware/cape-boneblack-hdmi-00A0.dtbo is not being read from
/lib/firmware at boot; do you know where it is being read from? Or can
you
Post by Robert Nelson
Post by Bit Pusher
point me to a link for the process and places of loading overlay files
on
Post by Robert Nelson
Post by Bit Pusher
the Ubuntu BBB at boot? I am really having difficulties finding
documentation regarding this so any helpful links are appreciated.
With the current kernel config, all "firmware" is built into the
kernel. We could disable that, but then it could take udev up to 60
seconds to actually find it on debian/ubuntu based systems. Best
thing to do is disable all the capes in uEnv.txt then write an init
script to load that specific *.dtbo into the slot early in bootup.
https://github.com/RobertCNelson/omap-image-builder/blob/master/target/init_scripts/capemgr-ubuntu.sh
Regards,
--
Robert Nelson
http://www.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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Robert Nelson
2014-03-12 22:00:54 UTC
Permalink
Post by Bit Pusher
start on runlevel 2
script
if test -f /etc/default/capemgr; then
. /etc/default/capemgr
fi
capemgr=$(ls /sys/devices/bone_capemgr.*/slots 2> /dev/null || true)
if [ ! "x${CAPE}" = "x" ] ; then
if [ ! "x${capemgr}" = "x" ] ; then
echo ${CAPE} > ${capemgr}
fi
fi
end script
I believe "capemgr=$(ls /sys/devices/bone_capemgr.*/slots 2> /dev/null ||
true)" is to resolve whether it is bone_capemgr.8 or .9
but I can not figure out how ${CAPE} is set? Thanks again.
Oh i have it setup to define "CAPE" in /etc/default/capemgr

like:
https://github.com/RobertCNelson/omap-image-builder/blob/master/target/init_scripts/capemgr

No reason, other then it's common in a lot of debian init scripts to do that...

Regards,
--
Robert Nelson
http://www.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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Bit Pusher
2014-03-12 21:44:16 UTC
Permalink
Thanks Robert, this is very useful information that I did not know.
Post by Bit Pusher
Post by Bit Pusher
Thanks John, this worked. I also tried modifying
/lib/firmware/cape-boneblack-hdmi-00A0.dts to remove the conflicts
(without
Post by Bit Pusher
disabling HDMI in /boot/uboot/uEnv.txt) , and then recompiled to make a
new
Post by Bit Pusher
/lib/firmware/cape-boneblack-hdmi-00A0.dtbo,
but dmesg still reported a conflict with P9_25 even though P9_25 and
mcasp0
Post by Bit Pusher
had been removed. This indicates to me that
/lib/firmware/cape-boneblack-hdmi-00A0.dtbo is not being read from
/lib/firmware at boot; do you know where it is being read from? Or can
you
Post by Bit Pusher
point me to a link for the process and places of loading overlay files
on
Post by Bit Pusher
the Ubuntu BBB at boot? I am really having difficulties finding
documentation regarding this so any helpful links are appreciated.
With the current kernel config, all "firmware" is built into the
kernel. We could disable that, but then it could take udev up to 60
seconds to actually find it on debian/ubuntu based systems. Best
thing to do is disable all the capes in uEnv.txt then write an init
script to load that specific *.dtbo into the slot early in bootup.
Regards,
--
Robert Nelson
http://www.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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Loading...