Whole camera/video kernel module stack loaded despite start_x=0

[MichaIng]

After updating the kernel v4.19 (many thanks for providing that btw 👍) I recognised that the whole camera/video kernel module stack is loaded:

2019-05-19 00:17:53 root@micha:/tmp# lsmod
Module                  Size  Used by
bcm2835_codec          36864  0
bcm2835_v4l2           45056  0
v4l2_mem2mem           24576  1 bcm2835_codec
bcm2835_mmal_vchiq     32768  2 bcm2835_codec,bcm2835_v4l2
v4l2_common            16384  1 bcm2835_v4l2
videobuf2_dma_contig    20480  1 bcm2835_codec
videobuf2_vmalloc      16384  1 bcm2835_v4l2
raspberrypi_hwmon      16384  0
videobuf2_memops       16384  2 videobuf2_dma_contig,videobuf2_vmalloc
videobuf2_v4l2         24576  3 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem
hwmon                  16384  1 raspberrypi_hwmon
videobuf2_common       45056  4 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem,videobuf2_v4l2
videodev              200704  6 bcm2835_codec,v4l2_common,videobuf2_common,bcm2835_v4l2,v4l2_mem2mem,videobuf2_v4l2
media                  36864  2 videodev,v4l2_mem2mem
vc_sm_cma              24576  1 bcm2835_mmal_vchiq
fixed                  16384  0

With last firmware packages it was possible to prevent that via start_x=0 or loading the cut down start file:

start_file=start_cd.elf
fixup_file=fixup_cd.dat

But now both have no affect on the kernel modules loading. Of course I can actively blacklist them, but IMO this should be possible via config.txt as well.

[6by9]

Previously the V4L2 camera module (bcm2835_v4l2) wasn't loaded automatically at all. This has been changed in the mainline kernel to become a platform driver, therefore it will be probed whenever the vchiq module is configured. It won't create any /dev/videoN devices if the camera isn't detected.

Secondly you now have bcm2835_codec which is providing video encode, decode, and transform functions via V4L2 M2M devices. That shares the majority of modules with bcm2835_v4l2, therefore there is significantly reduced net effect between loading the camera module or not. This is applicable to start.elf as well as start_x.elf.

One option would be to kill the vchiq node should you use the cutdown firmware, although that would lose audio too.

NB This is really a Linux kernel issue, not a firmware one.

[MichaIng]

@6by9 Okay many thanks for the explanation.

Hmm how could I kill the vchiq node? Since my system is headless, no need for audio either. Also this sounds like it would prevent some error messages when using 16M GPU mem share and/or:

hdmi_ignore_hotplug=1
hdmi_ignore_composite=1

Actually I would still love to have an officially documented headless option, which disables all A/V features/modules/overlays. But I know about the non-avoidable kernel error traces on boot when using the above, so as long as this cannot be worked around, it confuses users too much to document the settings officially.

[6by9]

https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/bcm2708-rpi.dtsi#L71 You'll want a dtoverlay or similar setting status="disabled" in that node.

https://github.com/raspberrypi/linux/blob/rpi-4.19.y/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c#L3669 is the code from vchiq that loads in the other drivers.

[MichaIng]

@6by9 I never really fiddled with custom dtoverlay setup, would something like this work: dtoverlay mailbox status="disabled" or ~dtoverlay bcm2835-vchiq status="disabled"~ EDIT: Ah okay, I need to create a new overlay that then adjusts the nodes setting. Definitely something I need to dig into first 😄.

Actually those kernel errors on boot are due to the related overlay/module being disabled, right? bcm2708_fb: probe of soc:fb failed with error -22

[pelwell]

Try this:

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2835";

    fragment@0 {
        target-path = "/soc/mailbox@7e00b840";
        __overlay__ {
            status = "disabled";
        };
    };
};

Save it as novchiq-overlay.dts and compile with:

$ dtc -@ -I dts -O dtb -o novchiq.dtbo novchiq-overlay.dts

Copy the resulting file to /boot/overlays and add dtoverlay=novchiq to config.txt.

[MichaIng]

@pelwell Many thanks. Worked like a charm:

2019-05-19 22:30:57 root@micha:~# lsmod
Module                  Size  Used by
raspberrypi_hwmon      16384  0
hwmon                  16384  1 raspberrypi_hwmon
fixed                  16384  0

• Even all VCHI related kernel error messages on boot are gone. Looks much cleaner now 👍. Should be probably included in:

  hdmi_ignore_hotplug=1
  hdmi_ignore_composite=1

  ? Although if audio is affected as well, then not. There might be use cases where no video but audio feature are desired.

Quick question:

2019-05-19 22:33:44 root@micha:~# dtoverlay -l
No overlays loaded

• Is this expected for overlays added to config.txt?
• dtoverlay -a lists novchiq.

[MichaIng]

I added disabling framebuffer:

2019-05-19 23:04:03 root@micha:~# cat /mnt/sda/micha.dts
/dts-v1/;
/plugin/;

/ {
        compatible = "brcm,bcm2835";

        fragment@0 {
                target-path = "/soc/mailbox@7e00b840";
                __overlay__ {
                        status = "disabled";
                };
        };

        fragment@1 {
                target-path = "/soc/fb";
                __overlay__ {
                        status = "disabled";
                };
        };
};

• This made the bcm2708_fb error (+ two other related ones) on boot go away. Actually I thought this was already included in:

  hdmi_ignore_hotplug=1
  hdmi_ignore_composite=1

Last now is: bcm2835-clk 3f101000.cprman: pllh: couldn't lock PLL once for each CPU (it seems) with full error trace. Actually the most nasty one, visually. Not sure where this is loaded from 🤔.

---

2019-05-19 23:21:21 root@micha:~# vcgencmd get_config int
VCHI initialization failed

• Good reason why this should not be supported officially, via dietpi.txt or such 😉.

[pelwell]

Quick question:

 2019-05-19 22:33:44 root@micha:~# dtoverlay -l
 No overlays loaded

Is this expected for overlays added to config.txt? dtoverlay -a lists novchiq.

Yes, that is expected. Overlays applied by the firmware from config.txt get merged into the DTB passed to the kernel - it can't tell that they are there, and it certainly can't remove them.

[MichaIng]

@pelwell Many thanks for the info guys.

The initial question was answered:

• v4.19 mainline kernel includes loading the camera related modules as long as vchiq is configured.
• One can disable VCHI completely via custom dtoverlay but since that disables audio + vcgencmd and most probably some other core features, this is nothing that can be supported officially.

  ---

  Since there is at least unofficially the following combination available

  hdmi_ignore_hotplug=1
  hdmi_ignore_composite=1

  to disable the framebuffer and video output completely (interesting for headless systems), it could disable /soc/fb as I did above to avoid several related error messages on boot. I am not sure about possible unwanted side effects, at least my RPi runs perfect with this. But I will open a separate issue about that.

[MichaIng]

If someone lands here, besides disabling whole VCHI, one can as well prevent loading of this bunch of camera related kernel modules by only blacklisting bcm2835_codec and bcm2835_v4l2. Those two pull all the others as dependencies. This keeps vcgencmd and audio available, but disables still video encode/decode. However on headless devices with 16M gpu_mem and thus start_cd.elf loaded, there is no point for this anyway.

Not 100% sure but perhaps it makes sense to prevent load of this two modules with start_cd.elf/16M memory share automatically, since this amount of memory anyway is not sufficient for any GPU-based features?

I am not wrong that 16M GPU memory share still automatically leads to start_cd.elf being loaded, am I?