yellow tinted framebuffer

[anyc]

I recently updated several RPis (2 and 3, with an own-built userland) from kernel 4.9.50 to 4.9.63 and 4.9.64. With these kernels, the framebuffer console has a yellow tint - text and background. If I downgrade the kernel again, the console is shown correctly - white text on black background. All Pis have a different type of monitor attached.

Does somebody have an idea what might cause this behavior?

I also tried different HDMI settings in config.txt like setting the mode manually but it does not help.
If I add dtoverlay=vc4-kms-v3d to config.txt, the console is shown correctly.

Thank you!

• Which model of Raspberry Pi?
  Right now, I have a the following two Pis at hand that show this behavior:
  ** Raspberry Pi 2 Model B Rev 1.1
  ** Raspberry Pi 3 Model B Rev 1.2
• Which OS and version (cat /etc/rpi-issue)?
  Own-built userland
• Which firmware version (vcgencmd version)?
  The firmware with the .64 kernel:
  Aug 6 2019 13:14:10
  Copyright (c) 2012 Broadcom
  version dd0dc7bd0bdbeb1ca6be21dc49847c7a5331457c (clean) (release) (start)

$ dmesg | grep -i fb
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=1600 bcm2708_fb.fbheight=900 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000   kgdboc=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait root=/dev/mmcblk0p2 rw rootwait rootfstype=btrfs quiet splash logo.nologo console=tty1 kgdboc= rootflags=subvol=@root
[    3.333521] simple-framebuffer 3e669000.framebuffer: fb0: simplefb registered!
[    4.415123] bcm2708_fb soc:fb: FB found 1 display(s)
[    4.424473] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 1600x900

config.txt

enable_uart=1
gpu_mem=256M

[pi2]
kernel=u-boot-rpi2.bin

[pi3]
kernel=u-boot-rpi3_a32.bin

[all]

I will try to debug why this fails:

/opt/vc/bin/vcdbg log msg
Failed to allocate -505734863 bytes for message buffer

$ /opt/vc/bin/vcgencmd get_config int  
aphy_params_current=819
arm_freq=900
audio_pwm_mode=514
config_hdmi_boost=5
disable_auto_turbo=1
disable_commandline_tags=2
disable_l2cache=1
disable_overscan=1
display_hdmi_rotate=-1
display_lcd_rotate=-1
dphy_params_current=547
enable_uart=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
init_uart_clock=0x2dc6c00
lcd_framerate=60
over_voltage_avs=0x1b774
pause_burst_frames=1
program_serial_random=1
sdram_freq=450
hdmi_force_cec_address:0=65535
hdmi_force_cec_address:1=65535
hdmi_pixel_freq_limit:0=0x9a7ec80
hdmi_pixel_freq_limit:1=0x9a7ec80

[popcornmix]

Can you confirm that the problem is purely kernel related? (e.g. same version of firmware shows the problem with newer kernel and not with older kernel)?

(I would have expected the firmware to be more likely to have an effect than kernel when running without kms/fkms overlay).

If that is true can you bisect the exact point in kernel tree when the problem started?

[anyc]

It starts with 4.9.52 (cbb5c28). I did not test .51 as its almost the same as .52. 4.9.50 (b220176) is working correctly.

I can try to bisect the exact commit but it looks like the commits in between are not always "buildable", e.g., the config seems to be missing.

Did the other distros switch to the vc4 overlays already? I wonder why I'm the only one that has this problems.

[anyc]

I don't know why but I cannot reproduce the results from last post. Now, 4.19.49 (4395da0) works and 4.19.50 (b220176) does not. This also looks more plausible due to the multitude of vc4 commits on top of 4.19.50.

[anyc]

I think I have the commit: 4600e91
"Pulled in the multi frame buffer support from the Pi3 repo"

[popcornmix]

@JamesH65 any ideas?

[JamesH65]

No ideas at all. All sounds extremely bizarre. @anyc Do you see the same issues with a new buster install, no userland changes, default config.txt etc

[anyc]

The problem does not occur with the Raspbian image.

If I enable the display output in uboot, it is shown correctly as well. During the kernel boot, I can see the blinking cursor in black and white for a few seconds.

I also tried booting my initramfs with the raspbian kernel and firmware files and the colors are wrong too.

I can't remember doing something special with the framebuffer or terminal.

To me, it looks like it is showing wrong colors as soon as userspace is starting to write to the terminal. Did some kernel structures change that are exchanged with userspace or something like that?

[anyc]

I just tried different firmware versions:

07937c7d48bcd44cc1015c6257ae2cfa5da51298 "kernel: Bump to 4.19.50"
works even with the latest 4.19.66 kernel

The following commit:

64b5649a41b69d09bfe0ed05448d28a66be3edfd "firmware: Updates for Pi4"

does not work with the 4.19.66 kernel.

I get the right colors with both firmwares if I use kernel 4.19.50.

[anyc]

I noticed the following differences in the kernel log when the output is right and tinted:

Correct output:

/ # dmesg | grep -i fb
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1200 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000
000  console=ttyS0,115200 kgdboc=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait root=/dev/mmcblk0p2 rw rootwait rootfstype=btrfs verbose initramfs_debug dwc_otg.lpm
_enable=0 initramfs_rescue console=ttyAMA0,115200 console=ttyS0,115200 kgdboc= rootflags=subvol=@root
[    3.367519] simple-framebuffer 3e330000.framebuffer: fb0: simplefb registered!
[    6.824962] bcm2708_fb soc:fb: Unable to determine number of FB's. Assuming 1
[    6.825175] bcm2708_fb soc:fb: FB found 1 display(s)
[    6.826061] bcm2708_fb soc:fb: Couldn't allocate a DMA channel
[    6.826261] bcm2708_fb soc:fb: probe failed, err -19
/ # dmesg | grep -i frame
[    3.288238] simple-framebuffer 3e330000.framebuffer: framebuffer at 0x3e330000, 0x8ca000 bytes, mapped to 0x(ptrval)
[    3.288281] simple-framebuffer 3e330000.framebuffer: format=a8r8g8b8, mode=1920x1200x32, linelength=7680
[    3.328199] Console: switching to colour frame buffer device 240x75
[    3.367519] simple-framebuffer 3e330000.framebuffer: fb0: simplefb registered!
[    7.344859] dwc_otg: Microframe scheduler enabled

Tinted:

[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1200 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000
000  console=ttyS0,115200 kgdboc=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait root=/dev/mmcblk0p2 rw rootwait rootfstype=btrfs verbose initramfs_debug dwc_otg.lpm
_enable=0 initramfs_rescue console=ttyAMA0,115200 console=ttyS0,115200 kgdboc= rootflags=subvol=@root
[    3.367528] simple-framebuffer 3e330000.framebuffer: fb0: simplefb registered!
[    6.824617] bcm2708_fb soc:fb: FB found 1 display(s)
[    6.840688] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 1920x1200
/ # dmesg | grep -i frame
[    3.288229] simple-framebuffer 3e330000.framebuffer: framebuffer at 0x3e330000, 0x8ca000 bytes, mapped to 0x(ptrval)
[    3.288272] simple-framebuffer 3e330000.framebuffer: format=a8r8g8b8, mode=1920x1200x32, linelength=7680
[    3.328192] Console: switching to colour frame buffer device 240x75
[    3.367528] simple-framebuffer 3e330000.framebuffer: fb0: simplefb registered!
[    6.840688] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 1920x1200
[    7.328692] dwc_otg: Microframe scheduler enabled

It looks like if bcm2708_fb (DMA?) initialization fails, the output looks correct.

[anyc]

The above was with kernel 4.19.66 and different firmware versions.
If I use a new firmware with kernel 4.19.50, I get the following output with correct colors:

/ # dmesg | grep -i fb
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1200 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000
000  console=ttyS0,115200 kgdboc=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait root=/dev/mmcblk0p2 rw rootwait rootfstype=btrfs verbose initramfs_debug dwc_otg.lpm
_enable=0 initramfs_rescue console=ttyAMA0,115200 console=ttyS0,115200 kgdboc= rootflags=subvol=@root
[    6.746846] BCM2708FB: allocated DMA memory 0xfad00000
[    6.746906] BCM2708FB: allocated DMA channel 0
/ # dmesg | grep -i frame
[    6.788112] Console: switching to colour frame buffer device 240x75
[    7.259192] dwc_otg: Microframe scheduler enabled

[anyc]

After removing Uboot from the config.txt, I also got correct colors and noticed that the "simple-framebuffer" log messages where gone as well. It looks like Uboot adds a framebuffer node to the device tree (u-boot/u-boot@6a195d2#diff-3608b9bd11b662336b1548828cd97e15) which the simple-fb module of the kernel will pick up and use. Maybe it does not play well with the new framebuffer patches and this is causing my issues?

Disabling simple-framebuffer in the kernel does not help as the kernel will not start. I had to patch Uboot to remove the simple-fb code, as it was hard-coded in the RPi board code although there is a CONFIG_ option available. But it looks like the kernel will not start as well. No output on the display or over the UART after Uboot started the kernel. :(

[anyc]

If I disable CONFIG_LCD_DT_SIMPLEFB and CONFIG_VIDEO_BCM2835 in Uboot the kernel framebuffer is shown correcty. So I guess the uboot driver configures the framebuffer in a way the new kernel driver does not like.

[6by9]

Daft thought - it's not trying to display an RGB565 buffer is it, and the lower bit depth is more obvious?
vcgencmd dispmanx_list should display a list of the planes that the GPU has put on the display.

[anyc]

Looks like you are right:

Wrong colors with uboot:
display:2 format:RGB565 transform:0 layer:-127 1920x1200 src:0,0,1920,1200 dst:0,0,1920,1200 cost:889 lbm:0

Right colors without display in uboot:
display:2 format:XRGB8888 transform:0 layer:-127 1920x1200 src:0,0,1920,1200 dst:0,0,1920,1200 cost:1156 lbm:0

It's strange though that the kernel (with wrong colors and distortion) shows:
simple-framebuffer 3e330000.framebuffer: format=a8r8g8b8, mode=1920x1200x32, linelength=7680
These values come from the device tree entry that uboot adds. Also fbset shows 32bit depth.

[6by9]

Well I know how the firmware sets up simplefb for use before vc4-fkms-v3d is loaded. That uses a gpu_mem allocation to reserve the memory. I have no idea how uboot is trying to reserve memory in this case.

The framebuffer mailbox APIs have changed slightly with the multiple framebuffer support, but they should all be backwards compatible (only talking to the primary framebuffer by default).

My other suspicion would be that you had managed to get multiple layers being rendered, but that doesn't appear to be the case.

[anyc]

I have both vc4 overlays disabled. Could this happen if simplefb and bcm2708_fb both try to configure the framebuffer? Because I can see the first lines of the kernel output correctly and after around 6 seconds - when the bcm2708_fb lines appear in the log - the output is corrupted.

[anyc]

I also tried to set the color depth in the config.txt but it didn't help.

[6by9]

simplefb is normally set up by the firmware having preallocated a framebuffer and passed it into the display hardware to be on the screen. The kernel can then scrawl whatever it likes into that.

It looks like u-boot's simplefb also goes through the same route as bcm2708_fb for configuring the framebuffer with the GPU allocating the buffer - https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-bcm283x/msg.c#L108

I suspect that you're ending up with /dev/fb0 (simplefb) and /dev/fb1 (bcm2708_fb). However both will be going through the same interface to the GPU, therefore simplefb is likely to be losing the buffer it had mapped. simplefb will still be rendering to the old buffer address, and you'll therefore get a moderate mess.

If u-boot is creating a simplefb device for the frame buffer, then it really should be ensuring that bcm2708_fb isn't configured. Generally speaking u-boot would be used with a mainline Linux kernel, and that wouldn't have bcm2708_fb present.

[byrondai]

I also encountered this problem. In the /dev, there are fb0 and fb1.

I tried to close the simple framebuffer in uboot but it didn't work.

Can anyone help me tell me how to close the simple framebuffer?

Thank you

[6by9]

I'd suggest you blacklist bcm2708_fb. Exactly how to do that may vary between distributions, but creating a file in /etc/modprobe.d/ with the contents blacklist bcm2708_fb would be the most common way.

[anyc]

6by9: Thank you! Do you know if bcm2708_fb provides any benefits over simplefb for Pis before v4?

[6by9]

6by9: Thank you! Do you know if bcm2708_fb provides any benefits over simplefb for Pis before v4?

bcm2708_fb supports a number of parameters such as changing the bit depth of the framebuffer as it knows how to communicate with the firmware. It can also do screen blanking.

simplefb literally stuffs a memory buffer on the screen and leaves it there forever. There is no control over it once it is created.

[anyc]

So, for a proper solution, bcm2708_fb could also read the simplefb device tree node and adopt the initial settings - but only if the simplefb module is disabled?

[BigMuscle85]

I updated from official 4.19.75 to 4.19.81 and now the frame buffer graphics is totally distorted. Console displays correctly, but the boot logo (that is simple 800x480 image copied to /dev/fb0) is rendered wrong. The framebuffer depth seems to be reduced to 16-bit. Adding framebuffer_depth=32 to /boot/config.txt does not help.

Is it the bug or has there been some change which I have to adapt to?

[6by9]

@BigMuscle85 Are you using u-boot? If yes then it is likely to be the same issue (mainly of u-boot) and you need to black-list bcm2708_fb.

[BigMuscle85]

I don't know what u-boot is, so probably not. It is just a plain Raspbian Lite Buster image. I noticed that even Xorg server displays 16-bit colors only. The current workaround is to execute "fbset -depth 32" in our boot script.

[6by9]

@BigMuscle85 See #3331. Independent regression to this u-boot issue.

[JamesH65]

This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

[JamesH65]

Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.