Could BB-BONELT-BT-00A0.dtbo have an error?

[Bit Pusher]

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:

                        slot@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";

        fragment@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

[Gerald Coley]

From the schematic you can see that thi spin is used as th eclock input for the HDMI. Please read the note.

Gerald

:

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

[Robert Nelson]

On Wed, Mar 12, 2014 at 11:24 AM, Bit Pusher <ken.w....@gmail.com> wrote:

> 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/

[Kenneth Martin]

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

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 beagleboard...@googlegroups.com.

[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

[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..

Gerald

--

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@googlegroups.com.

[John Syn]

From: Gerald Coley <ger...@beagleboard.org>
Reply-To: <beagl...@googlegroups.com>
Date: Wednesday, March 12, 2014 at 10:35 AM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Cc: Ken Martin <mar...@granitesemi.com>
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

On Wed, Mar 12, 2014 at 12:16 PM, Kenneth Martin <mar...@granitesemi.com> wrote:

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

On 14-03-12 12:37 PM, Robert Nelson wrote:

On Wed, Mar 12, 2014 at 11:24 AM, Bit Pusher <ken.w....@gmail.com> wrote:

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,

--

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@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[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.

Gerald

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Wed, Mar 12, 2014 at 4:05 PM, Bit Pusher <ken.w....@gmail.com> wrote:
> 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.

[Robert Nelson]

for reference, something like:

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

[Bit Pusher]

Thanks Robert, this is very useful information that I did not know.

[Bit Pusher]

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.

[Robert Nelson]

On Wed, Mar 12, 2014 at 4:58 PM, Bit Pusher <ken.w....@gmail.com> wrote:
> 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.

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...