Sharing a U-Boot bring-up finding that may help others debugging early video
on BeagleBone Black Rev D. The key lesson is that successful LCDC DMA does
not prove the LCDC signals have been routed to the external bridge.
This concerns a local video integration, not a demonstrated regression in
unmodified upstream U-Boot. Disabling CONFIG_PINCTRL is valid when board
code performs the required muxing; the missing piece here was that neither
path configured the LCDC pads for the BBB video setup.
Environment
- BeagleBone Black, EEPROM board identity A335BNLT, revision 00D0.
- Rev D ITE IT66122 bridge path.
- BeagleBoard U-Boot 2025.10, base commit
6825d60bea17774358f4199c4c7062801cfb931e. - Locally integrated TILCDC and ITE early-video support.
- CONFIG_PINCTRL disabled; board pinmux otherwise handled by legacy code.
- Linux video worked after its own driver initialization on the same board
and display connection.
Symptoms
The bridge was accessible, EDID could be read, and HPD indicated a connected
display. After resolving separate timing and controller-startup issues,
the raster completed its true-colour palette transfer and reported DMA
end-of-frame, but the display remained blank. The bridge did not report
VID_STABLE, so the output-enable path timed out.
Clock API readback and DMA status looked plausible. Neither was evidence
that pixel clock, DE, HSYNC, VSYNC or pixel data actually reached the bridge.
No conclusion about HDMI versus DVI could be drawn from EOF alone.
Missing pinmux path
The local device tree described the LCDC default pinctrl state. With
CONFIG_PINCTRL disabled, that declaration did not apply the pad settings.
In the frozen base source, the BBB path in
board/ti/am335x/mux.c:enable_board_pin_mux() configures other board
peripherals but does not configure the LCDC pad group. The generic LCD
group used by the GP EVM is not a drop-in replacement: it includes extra
GPMC data pads beyond the BBB HDMI data-pad group.
The existing nxp_hdmi_bonelt_pins group in
arch/arm/dts/am335x-boneblack-hdmi.dtsi provides the relevant BBB pad
settings, but a DT declaration alone cannot replace an active mux path.
Scoped fix and hardware result
The tested fix applies the following twenty pads explicitly, after checking
the board identity and before the local bridge/raster initialization:
| Pads | Settings |
|---|---|
| LCD_DATA0 through LCD_DATA15 | Mode 0, output, pull disabled |
| LCD_VSYNC, LCD_HSYNC, LCD_PCLK and LCD_AC_BIAS_EN (DE) | Mode 0, output, pull-down |
The implementation checks the functional pad-control bits by readback and
rejects a mismatch. It does not change GPMC, MMC, UART or other GPIO pads,
and does not introduce SPL video initialization.
With the remaining video configuration unchanged, the board operator
confirmed that the U-Boot image became visible. HDMI/DVI automatic selection
was retained; forcing the output protocol was not the pinmux fix.
Native and ARM32 user-mode tests with simulated MMIO also check the exact
pad offsets, values, write boundaries and failure on a bad readback. Those
tests do not replace the physical display result.
Suggestions and maintainer question
For early-video integrations, it would be useful to document or diagnose
the requirement that either the pinctrl driver or a board-specific legacy
path must apply the LCDC pads before enabling the bridge. Pad readback can
make the distinction between internal DMA progress and externally routed
signals much clearer.
A blanket dependency on CONFIG_PINCTRL may be inappropriate for boards with
a valid legacy mux path. The important requirement is an effective mux
implementation, not a DT pinctrl property by itself.
What is the preferred BBB-specific integration point for this in the
BeagleBoard U-Boot tree: the early-video adapter, a scoped board hook, or a
documented pinctrl configuration? Guidance would help prepare a minimal
upstreamable change rather than submitting local application-specific code.
Public source references
- Base board mux source:
u-boot/board/ti/am335x/mux.c at 6825d60bea17774358f4199c4c7062801cfb931e · beagleboard/u-boot · GitHub - Base BBB HDMI pin group:
u-boot/arch/arm/dts/am335x-boneblack-hdmi.dtsi at 6825d60bea17774358f4199c4c7062801cfb931e · beagleboard/u-boot · GitHub - Related Rev D bridge discussion (this report concerns U-Boot, not the
Linux-only issues in that thread):
BBB RevD (and Industrial) IT66122 issues