Are we missing overlay_map.dtb for RPi4?

It has bothered me that I keep reading that vc4-kms-v3d and vc4-kms-v3d-pi4 are redundant. However, on my system they behaved very differently, not only in results but on closer examination they load a very different set of kernel drivers.

Today I found this.

Are we missing the overlay_map.dtb file?

Edit: Here is a link on github, it shows how this file is used and possible implications of adding it. It could have a user impact, if it were to be installed, depending on what people have set in config.txt.

I don’t know the answer but I have a question by the way : we don’t have vcdbg on manjaro, do we ?

Not that I have been able to find. Maybe it is deemed too technical? But raspistill is also not available and that is a desktop app. I am not sure why. Maybe no one asked for them?

I know that raspicam is not here because I follow commits on userland and it’s written here : userland/CMakeLists.txt at master · raspberrypi/userland · GitHub

The raspi team doesn’t want to support 64bis right now : Revert "Add MMAL and MMAL_APPS to 64bit builds" · raspberrypi/userland@f97b1af · GitHub

But for vcdbg, I guess we can have one with this.

In my interpretation, the word redundant, is not a great choice of words. If you use dtoverlay=vc4-kms-v3d and you are running on a RPi4, it will instead load vc4-kms-v3d-pi4. So if you are already using dtoverlay=vc4-kms-v3d-pi4 there will be no change with the inclusion of this file. The benefit is the single setting of dtoverlay=vc4-kms-v3d will load the correct file for both rpi3 and rpi4.

No. That was a ubuntu misque by naming it overlay_map.dtb so it got put in /boot/ with all of the other .dtb’s. It was supposed to be overlay_map.dtbo and go in /boot/overlays/.

All overlays go in /boot/overlays. All RPi specific device firmware (.dtb’s) go in /boot/. These directories are where the RPi devices knows to look for the files to be loaded automatically. You can specify paths but why not let the pi do what it does?.

So that is an Ubuntu specific file? No such file on my system.

If so, I am back to being totally lost why vc4-kms-v3d behaves differently on my system.

Depends on how you look at it. The file naming was a mistake on their end. It was supposed to be .dtbo instead of .dtb.

All .dtb files have rpi device names in them. All .dtbo files are overlays.

Are you implying that I should have a /boot/overlays/overlay_map.dtbo file?

I thought so but looking here on mine in overlays it is overlay_map.dtb.

Rename it to overlay_map.dtbo and reboot to see if things work right.

This is a RPi mistake.

But I do not have an overlay_map.{anything} file on my system. Not in /boot, /boot/overlays or any directory indexed via mlocate.

This is a custom arch-arm 32 bit os I am on and the image boots more than one kernel so I had to do a separate pkgbuilld that just did overlays and .dtb’s. So guessing the mis-naming issue with RPi and me using *.dtbo to copy over to the pkg directory in the 64 bit kernel package.

I am going to upload this file for you to test.

Ok, but I first need to run to the hardware store and get back before the temp drops. I need to spray foam a spot in my well-house.

Unless it is quick :slight_smile:

Put this file in /boot/overlays and test.


After reading your link above a 2nd time it looks like it is really supposed to be overlay_map.dtb instead of overlay_map.dtbo in /boot/overlays. Rename the file and put it in /boot/overlays.

Quote (Ubuntu uses a different file structure):

Canonical are now aware of the problem and it should be fixed in future releases. For now you have the easy workaround of copying /boot/firmware/overlay_map.dtb into /boot/firmware/overlays/ after installation.

It works as /boot/overlays/overlay_map.dtb


$ lsmod | grep vc4

vc4                   274432  32
cec                    69632  1 vc4
drm_kms_helper        262144  3 vc4
snd_soc_core          245760  1 vc4
snd_pcm               126976  5 vc4,snd_compress,snd_soc_core,snd_pcm_dmaengine
drm                   561152  20 gpu_sched,drm_kms_helper,v3d,vc4

Before (see below) it would load bcm drivers rather than the vc4.

$ lsmod | grep bcm

bcm2835_codec          49152  0
bcm2835_isp            32768  0
bcm2835_v4l2           45056  0
bcm2835_mmal_vchiq     32768  3 bcm2835_codec,bcm2835_v4l2,bcm2835_isp
videobuf2_vmalloc      20480  1 bcm2835_v4l2
v4l2_mem2mem           45056  1 bcm2835_codec
snd_bcm2835            28672  0
videobuf2_dma_contig    24576  2 bcm2835_codec,bcm2835_isp
videobuf2_v4l2         32768  4 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem,bcm2835_isp
videobuf2_common       61440  5 bcm2835_codec,videobuf2_v4l2,bcm2835_v4l2,v4l2_mem2mem,bcm2835_isp
snd_pcm               126976  1 snd_bcm2835
videodev              286720  6 bcm2835_codec,videobuf2_v4l2,bcm2835_v4l2,videobuf2_common,v4l2_mem2mem,bcm2835_isp
mc                     61440  6 videodev,bcm2835_codec,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem,bcm2835_isp
snd                    98304  3 snd_bcm2835,snd_timer,snd_pcm
vc_sm_cma              36864  2 bcm2835_mmal_vchiq,bcm2835_isp
i2c_bcm2835            16384  1
i2c_bcm2708            16384  0
1 Like

Great find!!!

Glad it is working.

Not sure to understand everything… so here are my questions :

  • do we have to install this .dtb by our own ?
  • can you please look at the userland thing and see if we can get vcdbg ? BTW there are commits from january for this code, maybe at least you can update it ?

Use the file I posted above until the next kernel hits. Should be soon.

Quote from the git README:

Note that this repository does not contain the source for the edidparser and vcdbg binaries due to licensing restrictions.

So only available binary will be 32 bit that they provide.

I can do that.

Done. New file uploaded with correct name.

1 Like