[Pironman5 Pro Max] TFT display shows white screen — no TFT support found in pironman5 1.3.7

General
1

Hello,

I recently set up a Pironman5 Pro Max with Raspberry Pi 5 and Raspberry Pi OS (Bookworm, 64-bit), and the TFT display remains white at all times.

Environment:

  • Hardware: Pironman5 Pro Max
  • SBC: Raspberry Pi 5
  • OS: Raspberry Pi OS Bookworm 64-bit
  • pironman5 version: 1.3.7 (installed via official install script)

What I confirmed:

  • The TFT is detected as a display by the system
  • Touch input from the TFT is recognized
  • OLED is working correctly
  • SPI is enabled in /boot/firmware/config.txt (dtparam=spi=on)
  • pironman5 service is active and running
  • No errors in systemctl status pironman5

What I found:
Searching the installed source files, there appears to be no TFT-related code in pironman5 1.3.7:

grep -r "tft\|TFT\|lcd\|LCD" /opt/pironman5/ --include="*.py" -l

No pironman5-specific files were returned.

Also, the latest release on GitHub appears to be 1.2.21, while the install script installed 1.3.7 — could this be a pre-release or development version?

Question:
Is TFT display support planned or currently under development for Pironman5 Pro Max? Is there any additional configuration or package required to enable it?

Thank you!

2

Are you referring to the 4.3-inch TFT screen that comes with the Pro Max?

This 4.3-inch DSI screen is plug-and-play. However, be careful not to connect it incorrectly — it uses a cable similar to the camera cable, but the connector orientation is opposite, and the cable is relatively short.

3

That’s right.

The FPC is connected to the monitor (the shorter one).

The symptoms include whiteout, flashing primary colors, and severe noise.

I investigated with Claude, but he said it’s beyond his area of ​​expertise.

Therefore, a hardware failure is also being considered.

The following is a text from the AI.

After thorough software-side investigation, I’m now considering the
possibility that the FPC cable in my unit may be marginal — perhaps
damaged during assembly given the tight enclosure and the bend
required. Could you please send a replacement DSI FPC cable for the
4.3" panel? I’d like to rule out a hardware fault before pursuing
further driver debugging. Order details / receipt available on request.

4

Update with physical-setup confirmation, full investigation, and a
question about what differs between my unit and working units.

Physical setup confirmation

Following your reply, I have re-verified the physical assembly:

  • The 4.3" DSI display is connected with the short, reverse-orientation
    FPC cable explicitly labeled DSI — not the longer camera cable.
  • The cable is fully seated at both ends with both latches closed.
  • Connector orientation matches the assembly guide.
  • Power: 27W USB-C PD supply. vcgencmd get_throttled returns 0x0
    throughout testing.

Setup procedure followed

This matches the official documentation:

  1. Fresh Raspberry Pi OS Trixie 64-bit
  2. sudo apt update && sudo apt full-upgrade
  3. git clone -b pro-max GitHub - sunfounder/pironman5: Code for Raspberry Pi 5 case (Pironman5) · GitHub --depth 1
  4. cd ~/pironman5 && sudo python3 install.py
  5. sudo reboot

Post-install state: OLED, RGB fans, IR receiver, and TFT touch input
all work correctly. Only the TFT image output fails.

Investigation summary

I tested three configurations to isolate the failure point.

Config 1: dtoverlay=vc4-kms-dsi-waveshare-800x480

  • Driver: panel-dsi-generic, lanes=1, no panel-specific init.
  • DSI-2 comes up at 800x480@60Hz, desktop routed there.
  • Display: severe chromatic noise. Faint outline of a taskbar visible
    at the top edge; rest is fine RGB pixel noise on white.

Config 2: dtoverlay=vc4-kms-dsi-waveshare-panel-v2

  • Driver: panel-waveshare-dsi-v2 with smart-MCU autodetect via I2C@0x45.
  • Panel reports: hw_id = 0x8b, size = 139, mcu version = 0x8b.
  • Driver matches this to “waveshare,10.1-dsi-touch-a”, applies 800x1280
    portrait mode and Goodix touch. The touch driver then fails:
    “Goodix-TS 11-005d: I2C communication failure: -121”
    (because the actual touch IC is FT5406, not Goodix).
  • Display: black.

Config 3 (current): display_auto_detect=1, no manual DSI overlay

  • Firmware autodetect attaches: name=tc358762 channel=0 lanes=1.
  • DSI-2: 800x480@60Hz, position 0,0, Enabled: yes.
  • rp1dsi_bind succeeded in dmesg — no errors.
  • grim -o DSI-2 captures a perfect 800x480 desktop screenshot:
    wallpaper, taskbar, clock, icons, cursor all rendered correctly.
    Two consecutive grim captures are byte-identical — the framebuffer
    is stable and complete.
  • However, the physical TFT does NOT display this content. Instead it
    cycles through solid primary/secondary colors (cyan, white, green)
    at roughly 1-second intervals — characteristic of a panel falling
    back to its internal BIST/test pattern when no valid DPI signal
    arrives.

Diagnosis

The break is somewhere between the DSI HS data lanes reaching the
TC358762 bridge IC and the DPI output reaching the LCD itself.
Everything upstream of TC358762 (compositor, framebuffer, DSI
controller, low-power negotiation, I2C) verifiably works; the panel
shows valid touch input and the firmware autodetected the bridge
correctly.

I cannot determine from software alone whether this is:
(a) a system-level mismatch in DPI timings between the auto-loaded
overlay (presumably vc4-kms-dsi-7inch, designed for the Pi 7"
panel) and the Pro Max 4.3" panel’s actual requirements, OR
(b) a marginal/damaged DSI HS data lane on the FPC cable or an
internal panel issue.

What I’d like to ask

Other users in this forum have reported the Pro Max 4.3" display
working out-of-the-box (e.g. thread #4460, github issue #54), which
means my unit is clearly an outlier — not a uniformly reproducible
bug. To narrow down whether the cause is system-side or hardware-side
on my unit specifically:

  1. Could you share the output of:
    cat /boot/firmware/config.txt | grep -E ‘dtoverlay|display’
    from a known-working Pro Max image? If my config matches but my
    panel still fails, the cause is most likely hardware on my unit.

  2. Are there any known FPC cable batch issues with the 4.3" DSI
    cable shipped with the Pro Max? Should I request a replacement
    cable as a first step?

  3. Is there a hardware self-test mode on the panel itself that can
    confirm the LCD is functional independent of DSI input?

I can share full dmesg, the grim screenshot proving the framebuffer
is correct, the decompiled sunfounder-pironman5promax.dts, and a
short video of the BIST test-pattern cycling on request.

Thank you for your time.

5

Please contact service@sunfounder.com to get further help.