Raspberry Pi 5 firmware ignores and responds with incorrect frame buffer pixel depth information

[CodexTextor]

Describe the bug

The pixel depth set using the frame buffer property tags is being ignored and incorrectly reported as 32 bit when in fact it is 16 bit on the Raspberry Pi 5.

To reproduce

Assemble and link the bare metal code inside fw-bug.tar.gz using a sufficiently recent release of GNU binutils compiled for an aarch64-unknown-none target and a make tool conformant to POSIX, and then boot a Raspberry Pi 5 with the generated kernel8.img and the provided config.txt file.

Expected behaviour

The screen should turn solid green, indicating that the frame buffer's size matches the requested and reported dimensions and pixel depth.

Actual behaviour

The screen turns solid red, indicating that the frame buffer's size do not match its reported dimensions and pixel depth.

System

Check out the attached raspinfo.txt.gz.

[popcornmix]

Officially firmware side display driver (aka fkms) is no longer supported on pi0-4 and has never been supported on pi5 (the more basic support present is for test purposes).

The arm side driver is all that is supported.

Unfortunately for bare metal, that makes driving the display much more involved.
The linux kernel source does provide a template for what needs to be done, but I accept it is not trivial.

I'll take a look and see if there's a simple fix to your issue, but there won't be significant work done on this code (which is not used by anyone except bare metal, or someone trying to triage a bug in the kernel driver).

[6by9]

Officially firmware side display driver (aka fkms) is no longer supported on pi0-4 and has never been supported on pi5 (the more basic support present is for test purposes).

Technically this is the older framebuffer API, not the FKMS extension.
0x48001 is SET_ALLOCATE_BUFFER
0x48003 is SET_PHYSICAL_WIDTH_HEIGHT.
0x48005 is SET_DEPTH
With no DispmanX it's likely that implementing any of those functions is going to be far harder.

(FKMS uses SET_PLANE (0x48015), SET_TIMING (0x48017) and a few other mailbox properties).

[timg236]

Yes, Pi5 firmware has a fixed format framebuffer, it can be configured via config.txt.
I think it's unlikely that we would want to start implementing new display functionality in the GPU blob.

[CodexTextor]

Officially firmware side display driver (aka fkms) is no longer supported on pi0-4 and has never been supported on pi5 (the more basic support present is for test purposes).

OK, thanks! I was going to report another issue in the set plane tag used by the fKMS driver, but since that's no longer supported either then I won't bother.

To me I'm fine as long as the firmware provides a minimal interface to configure HDMI video and DSI, as I know how to drive the HVS and HDMI audio so I can take over from there.

Not sure whether I should close this or leave it open since @popcornmix said they'd still look into the issue.

[Satyria-RPI]

Yes, Pi5 firmware has a fixed format framebuffer, it can be configured via config.txt. I think it's unlikely that we would want to start implementing new display functionality in the GPU blob.

How can the framebuffer be changed using "config.txt"? And what resolution and color depth does the framebuffer have for testing purposes?

[timg236]

The legacy (debug) framebuffer resolution is non-configurable 640x480,720p,1080p and is actually just the bootloader diagnostic screen.
I believe framebuffer_depth and framebuffer_swap (BGRA vs ARGB) in config.txt still work but that's about it.