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.