Kernel 4.1.10: UART5 overlay can't claim nxp_hdmi_bonelt_pins

Running 4.1.10 kernel on BBB with Robert Nelson’s overlays. BB-SPIDEV1 works fine, but BB-UART5 fails. Message is

pinctrl-single 44e10800.pinmux: could not request pin 49 (44e108c4.0) from group pinmux_bb_uart5_pins on device pinctrl-single

Investigation shows that pins 48 and 49 are part of the nxp_hdmi_bonelt_pins pingroup:

group: nxp_hdmi_bonelt_pins
pin 108 (44e109b0.0)
pin 40 (44e108a0.0)
pin 41 (44e108a4.0)
pin 42 (44e108a8.0)
pin 43 (44e108ac.0)
pin 44 (44e108b0.0)
pin 45 (44e108b4.0)
pin 46 (44e108b8.0)
pin 47 (44e108bc.0)
pin 48 (44e108c0.0)
pin 49 (44e108c4.0)

And the mode is set to hdmi:

root@vesta:/opt/scripts/src/arm# cat $PINS | grep ’ 48| 49’
pin 48 (44e108c0.0) 00000008 pinctrl-single
pin 49 (44e108c4.0) 00000008 pinctrl-single

The hdmi overlay is not loaded according to capemanager:

root@vesta:/opt/scripts/src/arm# cat $SLOTS
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-UART5

Do I need to recompile the kernel with the hdmi bits commented out, or is there an easier way?

Please read the "BBB compatibility issues:" section of:


Thank you so much - I missed that little detail, or perhaps I used an earlier version. Works like a champ.

It's more like, someone (me) forget to fully document every option,
and now that users are testing v4.1.x we are finding gaps in my
directions. :wink:


It’s more like, someone (me) forget to fully document every option,
and now that users are testing v4.1.x we are finding gaps in my
directions. :wink:

How sloppy of you Robert. What on earth could possibly keep you so busy that you forget to document something ? :wink:

Yeah, I’m kidding of course.


I have kernel version 4.1.10-bone16 with the same issue as pbft. I tried following the “Compatibility issues section”.
I did the following and rebooted:

When I load BB-UART5 and check dmesg I get the following:

I also tried adding the line “Disable: HDMI” to uEnv.txt, but didn’t change the behavior.

What am I missing here? My final objective is actually to disable the HDMI to use the pins for the PRU.

Thank you very much for the help! It is quite impressive that almost every post I see about beaglebone I see the name Robert Nelson.

This is a sign that your still booting the original dtb:

Do you have a usb serial debug cable?

We need to look and see what u-boot is doing and if it's correctly loading
the custom:

dtb=am335x-boneblack-emmc-overlay.dtb from /boot/uEnv.txt


Thank you very much for the response!
The problem is solved now. I am going to post here to help whoever might have a similar issue.

My situation was that I had a flasher image with an old 3.8.13 kernel.
Then I would update the kernel to a version 4.1.x. It seems like a big leap like that might give problems, because it was ignoring my changes to uEnv.txt.

The solution was to get the jessie version from and flash my beagle with it.
Then you can change to a 4.1x kernel of choice if you want and when you change uEnv.txt file, it will be applied on reboot.