BeagleBone Black (BBB) HDMI issue


I have encountered a problem with HDMI with the BBB and the latest Debian 9.3 image.

When using a 4D systems LCD Cape, the latest Debian image works fine “out of the box” and when the BBB boots, the LCD cape correctly displays the desktop.

When I attempt to connect an HDMI display to the HDMI port instead (no LCD cape), there is no output from the BBB on the HDMI display.

I tried this on a BBB with an older debian image (I think it was factory programmed Debian 8.3 image). The older debian image booted and correctly displayed the desktop on a connected HDMI display.

I think I have some sort of configuration issue but I cannot determine what is wrong. /boot/Env.txt does not disable the HDMI virtual cape (the line is commented out):


and overlays are enabled:


I downloaded one of the recent images (5-20-2018) and tried that. Still no HDMI output.

I will also mention that I used two different HDMI displays to test with. One is an ASUS monitor and the other is the Manga Screen 2. Both displays work fine when plugged into my Mac.

Here is the output of

dogtag:[ Debian Image 2018-05-20]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.03-00002-gac9cce7c6a]:[location: dd MBR]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[ 1.031151] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[ 1.032748] gpio-of-helper ocp:cape-universal: ready

Any assistance would be appreciated. Thank you.


Hi Steve,

At first glance, this might be a regression, we just switched to v4.14.x a few weeks back.

The first thing i’d try, does your monitor have a usb hub built-in, aka something we can use to share a GND connect between the BBB and the monitor? (by connected a usb cable between both devices, thus allowing the edid register to be probed correctly.)

If that doesn’t work, does downgrading to 4.9.x fix the issue?

cd /opt/scripts/tools/
sudo ./ --lts_4_9
sudo reboot



The ASUS monitor does not have a USB hub.

The Manga Screen 2 is powered from the BBB USB port so I believe there is a shared GND connection through that. The Manga Screen 2 worked when I was using the older Debian image (8.3 I think) so I think the edid can be probed by the BBB.

I’ll try downgrading and see what happens and let you know.

Thank you,


Hi Robert,

I downgraded the kernel to 4.9.88:

info: you are running: [4.14.40-ti-r50], latest is: [4.9.88-ti-r111] updating…

but that hasn’t brought the HDMI display back to life.

Note, there is a typo in the command above to downgrade for anyone reading this. The correct option syntax is:

sudo ./ --lts-4_9

The first time I ran it with the underscore instead of the “-” and I “downgraded” to the same version I was running.

Thanks for taking the time to respond to me. Any other suggestions?


Is there a way to parse the edid using the serial port? I followed the instructions on:

but the following directory does not exist:


I think this is likely because the instructions are from 2017 and likely for a different version of the kernel?



give this a try in /boot/uEnv.txt


and enable/change the line with the edid override:

1024x768@60e -> 1088x1920@60e



Hi Robert,

I do recall attempting the edid override you suggested and it did not change things. I’ll try the audio disable as well and see what happens …

… so with disable_uboot_overlay_audio=1 and the edid override, the display is still off.

It is important to note that my ASUS monitor does not connect either so I don’t think this is an issue with the display. I connected the display to the HDMI port of my MBP and it works fine.

I get the sense that the HDMI drivers are simply not loaded at all. Is there someway to find out if they are even loading?


The tilcd/hdmi driver is built-in to the kernel in v4.9.x/v4.14.x.

So you won’t see them in lsmod, and they will be loaded very early after u-boot jumps into the kernel.



I tried downgrading to 4.4 but that didn’t change things either. I have since restored the kernel back to 4.14.