From: Jonathan Gray <jsg@jsg.id.au>
Subject: Re: sysutils/u-boot/rpi: framebuffer fix
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: mglocker@openbsd.org, sthen@openbsd.org, tech@openbsd.org, ports@openbsd.org, justin.berthault@zaclys.net
Date: Sun, 28 Sep 2025 14:37:36 +1000

On Sat, Sep 27, 2025 at 05:13:08PM +0200, Mark Kettenis wrote:
> As reported by Justin Berthault on bugs@, the raspberrypi-firmware
> update has resulted in a change of the pixel format of the framebuffer
> on the Raspberry Pi 400.  Instead of RGB it is now BGR.  Unfortunately
> the device tree still says that the pixel format is RGB.  The same
> thing happens on the Raspberry Pi 4B.
> 
> The situation is a bit of a mess.  There is a firmware call to set the
> pixel format, and U-Boot uses this call to request RGB.  However it
> seems that this firmware call wasn't actually implemented until
> somewhere in 2024.  The previous firmware we used was from 2021, so
> the call didn't actually do anything.  Luckily the firmware has been
> using RGB as the default pixel format for almost a decade.  Only
> really old firmware used BGR.
> 
> Unfortunately when the call was implemented, it doesn't actually do
> what it says on the tin.  Accoring to the documentation here:
> 
>   https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#get-pixel-order
>   https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#set-pixel-order
> 
> 0 means BGR and 1 means RGB.  However, in reality it seems that 0
> means "do nothing" and 1 means "swap between BGR and RGB".
> Unfortunately that also means that the call to get the pixel order
> state also just tells us whether it is swapped or not.
> 
> For some reason this pixel format issue doesn't seem to affect the
> Raspberry Pi 5.
> 
> I'm not sure I fully understand the issue yet.  But the following diff
> seems to yield the desired result, both with the old and the new
> firmware.  So I propose we use this as a workaround until we can
> figure out what is really going on.

https://github.com/raspberrypi/firmware/issues/1320#issuecomment-2088729072

"It turns out that the framebuffer_swap option in config.txt defaults to
enabled, so I have made it that the mailbox pixel_order field will flip
it with regard whatever framebuffer_swap sets the default order to."

> 
> ok?

ok jsg@

> 
> 
> Index: sysutils/u-boot/rpi/Makefile
> ===================================================================
> RCS file: /cvs/ports/sysutils/u-boot/rpi/Makefile,v
> diff -u -p -r1.1 Makefile
> --- sysutils/u-boot/rpi/Makefile	12 Aug 2025 12:24:48 -0000	1.1
> +++ sysutils/u-boot/rpi/Makefile	27 Sep 2025 13:52:30 -0000
> @@ -1,4 +1,5 @@
>  VERSION=	2025.07
> +REVISION=	0
>  
>  SOC=		rpi
>  
> Index: sysutils/u-boot/rpi/patches/patch-drivers_video_bcm2835_c
> ===================================================================
> RCS file: sysutils/u-boot/rpi/patches/patch-drivers_video_bcm2835_c
> diff -N sysutils/u-boot/rpi/patches/patch-drivers_video_bcm2835_c
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ sysutils/u-boot/rpi/patches/patch-drivers_video_bcm2835_c	27 Sep 2025 13:52:30 -0000
> @@ -0,0 +1,12 @@
> +Index: drivers/video/bcm2835.c
> +--- drivers/video/bcm2835.c.orig
> ++++ drivers/video/bcm2835.c
> +@@ -24,7 +24,7 @@ static int bcm2835_video_probe(struct udevice *dev)
> + 		return -EIO;
> + 
> + 	debug("bcm2835: Setting up display for %d x %d\n", w, h);
> +-	ret = bcm2835_set_video_params(&w, &h, 32, BCM2835_MBOX_PIXEL_ORDER_RGB,
> ++	ret = bcm2835_set_video_params(&w, &h, 32, 0,
> + 				       BCM2835_MBOX_ALPHA_MODE_IGNORED,
> + 				       &fb_base, &fb_size, &pitch);
> + 	if (ret)
> 
>