linux
linux copied to clipboard
raspberrypi
Using a CM3+, `vc4-kms-v3d` causes framebuffer to be RGB565, but `vc4-kms-v3d-pi4` causes it to be RGB8888 (which is what it should be).
Describe the bug
I'm using a CM3+ with a 7" TFT LCD display. The display is connected to the CM3+ through an HDMI-to-TFT converter.
Everything works fine except, when booting, the firmware stage's framebuffer depth is 32-bit (RGB8888) as it should be, but about half way through booting the OS, the framebuffer switches to 16-bit (RGB565). kernel.log shows this switch with the line fb0: switching to vc4 from simple. and the output of fbset shows rgba 5/11,6/5,5/0,0/0
I tried changing the config.txt file to dtoverlay=vc4-kms-v3d-pi4 to see what would happen, and the framebuffer remained 32-bit (RGB8888) which is what I need it to be. Unfortunately, I can't use vc4-kms-v3d-pi4 with the CM3+. I need vc4-kms-v3d to keep the framebuffer 32-bit (RGB8888) through the entire boot process.
Steps to reproduce the behaviour
- Use the following settings in config.txt:
# LCD display settings
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt 800 480 60 6 0 0 0
hdmi_edid_file=1
dtoverlay=vc4-kms-v3d
- After booting to a console, run
fbsetand notice the following output:
mode "800x480"
geometry 800 480 800 480 16
timings 0 0 0 0 0 0 0
accel true
rgba 5/11,6/5,5/0,0/0
endmode
-
Change the config.txt file to
dtoverlay=vc4-kms-v3d-pi4 -
After booting to a console, run
fbsetand notice the following output:
mode "800x480"
geometry 800 480 800 480 32
timings 0 0 0 0 0 0 0
rgba 8/16,8/8,8/0,8/24
endmode
Device (s)
Raspberry Pi CM3+ Lite
System
OS and Version: Raspberry Pi OS Bullseye 32-bit (Downloaded today) Raspberry Pi reference 2022-04-04 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 226b479f8d32919c9fe36dd5b4c20c02682f8180, stage4
Firmware Version: May 24 2022 13:25:56 Copyright (c) 2012 Broadcom version 2c647ef4127e289d4a0cb5cfbb22855bfb7f1723 (clean) (release) (start)
Kernel Version: Linux raspberrypi 5.15.41-v7+ #1557 SMP Mon May 23 16:46:23 BST 2022 armv7l GNU/Linux
Logs
kernel.log when using dtoverlay=vc4-kms-v3d. Notice the fb0: switching to vc4 from simple about 10 seconds in.
...
May 26 20:47:51 raspberrypi kernel: [ 8.543792] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
May 26 20:47:51 raspberrypi kernel: [ 8.543821] [vc_sm_connected_init]: start
May 26 20:47:51 raspberrypi kernel: [ 8.568694] [vc_sm_connected_init]: installed successfully
May 26 20:47:51 raspberrypi kernel: [ 8.619604] videodev: Linux video capture interface: v2.00
May 26 20:47:51 raspberrypi kernel: [ 8.699760] random: crng init done
May 26 20:47:51 raspberrypi kernel: [ 8.699790] random: 7 urandom warning(s) missed due to ratelimiting
May 26 20:47:51 raspberrypi kernel: [ 8.786130] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
May 26 20:47:51 raspberrypi kernel: [ 8.789226] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
May 26 20:47:51 raspberrypi kernel: [ 8.811577] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
May 26 20:47:51 raspberrypi kernel: [ 8.836856] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
May 26 20:47:51 raspberrypi kernel: [ 8.847667] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
May 26 20:47:51 raspberrypi kernel: [ 8.893620] bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video13
May 26 20:47:51 raspberrypi kernel: [ 8.894656] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
May 26 20:47:51 raspberrypi kernel: [ 8.896676] bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video14
May 26 20:47:51 raspberrypi kernel: [ 8.896962] bcm2835_audio bcm2835_audio: there is not valid maps for state default
May 26 20:47:51 raspberrypi kernel: [ 8.897800] bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video15
May 26 20:47:51 raspberrypi kernel: [ 8.899111] bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video16
May 26 20:47:51 raspberrypi kernel: [ 8.899160] bcm2835-isp bcm2835-isp: Register output node 0 with media controller
May 26 20:47:51 raspberrypi kernel: [ 8.899186] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
May 26 20:47:51 raspberrypi kernel: [ 8.899209] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
May 26 20:47:51 raspberrypi kernel: [ 8.899231] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
May 26 20:47:51 raspberrypi kernel: [ 8.906762] bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video20
May 26 20:47:51 raspberrypi kernel: [ 8.911754] bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video21
May 26 20:47:51 raspberrypi kernel: [ 8.913476] bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video22
May 26 20:47:51 raspberrypi kernel: [ 8.914875] bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video23
May 26 20:47:51 raspberrypi kernel: [ 8.915311] bcm2835-isp bcm2835-isp: Register output node 0 with media controller
May 26 20:47:51 raspberrypi kernel: [ 8.915356] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
May 26 20:47:51 raspberrypi kernel: [ 8.915379] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
May 26 20:47:51 raspberrypi kernel: [ 8.915402] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
May 26 20:47:51 raspberrypi kernel: [ 8.916157] bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp
May 26 20:47:51 raspberrypi kernel: [ 8.917926] bcm2835_audio bcm2835_audio: card created with 8 channels
May 26 20:47:51 raspberrypi kernel: [ 9.009596] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
May 26 20:47:51 raspberrypi kernel: [ 9.038785] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
May 26 20:47:51 raspberrypi kernel: [ 9.038854] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
May 26 20:47:51 raspberrypi kernel: [ 9.068753] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
May 26 20:47:51 raspberrypi kernel: [ 9.068821] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
May 26 20:47:51 raspberrypi kernel: [ 9.076157] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
May 26 20:47:51 raspberrypi kernel: [ 9.076229] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
May 26 20:47:51 raspberrypi kernel: [ 9.084952] bcm2835-codec bcm2835-codec: Device registered as /dev/video18
May 26 20:47:51 raspberrypi kernel: [ 9.085016] bcm2835-codec bcm2835-codec: Loaded V4L2 image_fx
May 26 20:47:51 raspberrypi kernel: [ 9.112872] bcm2835-codec bcm2835-codec: Device registered as /dev/video31
May 26 20:47:51 raspberrypi kernel: [ 9.112991] bcm2835-codec bcm2835-codec: Loaded V4L2 encode_image
May 26 20:47:51 raspberrypi kernel: [ 10.163939] cfg80211: Loading compiled-in X.509 certificates for regulatory database
May 26 20:47:51 raspberrypi kernel: [ 10.298500] checking generic (3ea83000 177000) vs hw (0 ffffffff)
May 26 20:47:51 raspberrypi kernel: [ 10.298537] fb0: switching to vc4 from simple
May 26 20:47:51 raspberrypi kernel: [ 10.299222] Console: switching to colour dummy device 80x30
May 26 20:47:51 raspberrypi kernel: [ 10.311420] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
May 26 20:47:51 raspberrypi kernel: [ 10.314968] Registered IR keymap rc-cec
May 26 20:47:51 raspberrypi kernel: [ 10.315235] rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
May 26 20:47:51 raspberrypi kernel: [ 10.315747] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input4
May 26 20:47:51 raspberrypi kernel: [ 10.378681] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
May 26 20:47:51 raspberrypi kernel: [ 10.426046] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
May 26 20:47:51 raspberrypi kernel: [ 11.661883] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
May 26 20:47:51 raspberrypi kernel: [ 11.680786] Registered IR keymap rc-cec
May 26 20:47:51 raspberrypi kernel: [ 11.681120] rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
May 26 20:47:51 raspberrypi kernel: [ 11.681546] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input5
May 26 20:47:51 raspberrypi kernel: [ 11.717327] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
May 26 20:47:51 raspberrypi kernel: [ 11.717896] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
May 26 20:47:51 raspberrypi kernel: [ 11.718365] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
May 26 20:47:51 raspberrypi kernel: [ 11.718797] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
May 26 20:47:51 raspberrypi kernel: [ 11.719337] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
May 26 20:47:51 raspberrypi kernel: [ 11.720067] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
May 26 20:47:51 raspberrypi kernel: [ 11.809972] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
May 26 20:47:51 raspberrypi kernel: [ 11.851429] Console: switching to colour frame buffer device 100x30
May 26 20:47:51 raspberrypi kernel: [ 11.851512] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device
May 26 20:47:51 raspberrypi kernel: [ 11.931755] rtl8192cu: Chip version 0x10
May 26 20:47:51 raspberrypi kernel: [ 12.075927] rtc-ds1307 1-0068: registered as rtc0
May 26 20:47:51 raspberrypi kernel: [ 12.077109] rtc-ds1307 1-0068: setting system clock to 2022-05-26T11:47:51 UTC (1653565671)
May 26 20:47:51 raspberrypi kernel: [ 12.104876] rtl8192cu: Board Type 0
...
Additional context
EDID File: edid.zip
Switching to vc4-kms-v3d-pi4 on a CM3 is likely to mean that it can't load, and therefore you remain with a simple frame buffer rather than DRM/KMS.
vc4_drv does request a 16bpp framebuffer for the DRM emulated framebuffer after commit https://github.com/torvalds/linux/commit/f741b28fb299263d2d03a0fb701bfe648927cd47.
If I read the docs correctly, then the command line mechanism referenced is adding a video= entry with the bpp specified, eg video=HDMI-A-1:1920x1080M-32@60, which you can add to /boot/cmdline.txt (do not add any carriage returns to that file - it must be one line).
@6by9 Thank you. Adding video=HDMI-A-1:800x480M-32@60 to cmdline.txt resolved the frame buffer color depth issue. It is now reporting 32-bit as it should.
However, when using vc4-kms-v3d, the driver still appears to be switching modes at fb0: switching to vc4 from simple in the kernel logs. This causes the screen to go blank and the splash screen to disappear prematurely. When using vc4-kms-v3d-pi4, that doesn't happen. Is there anything that can be done to resolve this symptom?
Using vc4-kms-v3d-pi4 on a CM3 is bogus. If you wish to compare between anything, compare between vc4-kms-v3d and nothing.
When vc4 loads it takes full control of the display pipeline from the firmware, resets everything, and chooses modes for itself. It creates new framebuffers, therefore anything that had already been written to them will be discarded. You could try building a custom kernel with all the required DRM modules built in so that they are loaded earlier in the boot sequence, but there is no guarantee that that is before your splashscreen.
Reopening because I think the firmware should pass the color depth to the kernel driver, or some other solution where there is better cooperation between the firmware and the driver so it doesn't need to be explicitly specified in the kernel command line.
Perhaps the firmware could pass the framebuffer_depth setting to the driver, or maybe this information could be encoded in the EDID somehow, and read by the driver.
Playing around with this a little more today, I discovered that the video= kernel command line argument is already being passed by default. Here's the output of cat /proc/cmdline when I do not add my own video= command line argument:
coherent_pool=1M snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 8250.nr_uarts=1 video=HDMI-A-1:800x480M@59 smsc95xx.macaddr=B8:27:EB:5A:5E:55 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=tty1 root=PARTUUID=fa782e0b-02 rootfstype=ext4 fsck.repair=yes rootwait logo.nologo quiet vt.global_cursor_default=0
So the video= command line argument is already there with the correct screen resolution, but it is missing the color depth information.
As per the commit text for https://github.com/torvalds/linux/commit/f741b28fb299263d2d03a0fb701bfe648927cd47
The preferred bpp for the fbdev emulation buffer has been 32 so far, which
means that by default we will allocate an 8MB buffer with a 1920x1080
resolution.
Worse this memory will be allocated from the CMA pool, and will never be
freed even if we don't use the fbdev emulation. Therefore, reducing it is a
big deal, and switching to 16bpp by default will gain us around 4MB at
1920x1080, while keeping decent color depth. And users still have the
option to switch to 32bpp using the kernel command line.
That is still true, and on a Pi0/1 that is a moderately large loss. A large majority of users will be booting into X at which point that buffer is not used.
framebuffer_depth defaults to 32, and changing that would affect a large number of users. I guess it would be possible to add a kms_framebuffer_depth parameter that adds to the video= line, but it's not a high priority seeing as users can edit the command line for themselves.
Switching to vc4-kms-v3d-pi4 on a CM3 is likely to mean that it can't load, and therefore you remain with a simple frame buffer rather than DRM/KMS.
vc4_drv does request a 16bpp framebuffer for the DRM emulated framebuffer after commit torvalds/linux@f741b28. If I read the docs correctly, then the command line mechanism referenced is adding a
video=entry with the bpp specified, egvideo=HDMI-A-1:1920x1080M-32@60, which you can add to /boot/cmdline.txt (do not add any carriage returns to that file - it must be one line).
@6by9
how long will this kernel cmd line be supported? will this be removed soon? and '@60' means 60Hz i guess? can i switch this to a different value at runtime?
how long will this kernel cmd line be supported? will this be removed soon? and '@60' means 60Hz i guess? can i switch this to a different value at runtime?
It's part of the core kernel code, and documented, therefore I wouldn't expect it to be dropped.
You should be able to reduce the command down to video=HDMI-A-1:-32 if you don't to specify the resolution/refresh rate.
If you do include resolution/refresh, then it only flags that mode as user preferred, and doesn't stop you changing it later.
We're not adding a kms_framebuffer_depth parameter as modifying the kernel command line is almost as easy, so closing.
(It looks like 6.6 has broken the use of video=HDMI-A-1:-32 in a refactor of that code. That's one to investigate, but is not this issue).