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

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

2

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

Gerald
:

image.png

3

"bone28" that's like from 6 months ago:

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

Regards,

4

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

5

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

6

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

7

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

8

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.

9

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,

10

for reference, something like:

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

Regards,

11

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

12

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.

13

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,