Skip to content

Disable hardware using dtoverlay #1577

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lucasfolino opened this issue May 12, 2021 · 5 comments
Open

Disable hardware using dtoverlay #1577

lucasfolino opened this issue May 12, 2021 · 5 comments

Comments

@lucasfolino
Copy link

I want to disable as much hardware as possible. Currently I can disable the Bluetooth and wifi using the dtoverlay in the config.txt. My question is can I do this for the audio or hdmi? Is this something that can be added if it is currently not available? My use case is that I am running a headless unit and using the PI as a server in my home lab for development. I have no use for the HDMI or the Audio to be enabled.

I have seen I can do this in Linux itself, but would rather remove them completely from the system seeing them. With Wifi and Bluetooth there is no software way to enable them without making configuration changes and rebooting. I want to have a standard config.txt and usercfg.txt file I can just copy over that can disable all of this than making OS configuration changes. I am in the process of making a small Pi farm for testing parallel programming and the plan is to have at least 8 Pis as servers. Being able to uniformly turn off as much hardware as possible would be nice. If this is a new feature what about also adding in turning off USB or any other hardware. This would make things clean and allow for a lot of scenarios. It would also make hardening the Pi better from security stand point.

For completeness I am using only Raspberry Pi 4s. This is a mix of 4GB and 8GB, but that shouldn't matter. I also am using them as a Pi-Hole and Octoprint so disabling unneeded hardware would be beneficial for that purpose as well.

@seamusdemora

This comment was marked as abuse.

@lucasfolino
Copy link
Author

No I did not.

@pelwell
Copy link
Contributor

pelwell commented Aug 2, 2021

I don't know how I missed this question - I would have told you that the Device Tree section of our Forums would be a better home since it's a question rather than an "issue". But since you've waited so long...

Disabling a hardware block using Device Tree is simply a matter of setting its status property to disabled, which causes it to be skipped over during the boot process. In a DT overlay this will take the form of a "fragment" that is targeted at the "node" for the hardware block, and that contains a payload to update the status property. For example, assuming there is a node called hdmi (more precisely, a node with the label hdmi) that you wish to disable, you would need something like this:

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2835";

    fragment@0 {
        target = <&hdmi>;
        __overlay__ {
            status = "disabled";
        };
    };
};

Disabling more blocks is a matter of finding their labels and appending new fragments with increasing numbers (fragment@1, etc.).

@lucasfolino
Copy link
Author

Sorry so many other projects do everything as an issue even questions. I will keep that in mind for future questions to look in the forums first. I honestly didn't realize there where official raspberry pi forums. I am a developer by trade so this was the first place I looked and saw similar comments and questions.

@MichaIng
Copy link

MichaIng commented Aug 3, 2021

Since in my case

cat /proc/device-tree/soc/hdmi@7e902000/status

shows disabled while I didn't create an overlay for it, probably it is controlled by the hdmi_ignore_hotplug=1 setting as well? But it does not really power down the HDMI plug. For that, tvservice -o is still required so save the ~0.1W power consumption.

In a headless scenario, with gpu_mem=16, max_framebuffers=0, and enable_tvout=0 (RPi4 only), the framebuffer and VC shared memory devices are still tried to be loaded, but fail, as of limited GPU features with <32 MiB memory and cut-down firmware start_cd.elf being loaded. So those can be disabled:

/dts-v1/;
/plugin/;
/ {
        compatible = "brcm,bcm2835";
        fragment@0 {
                target-path = "/soc/fb";
                __overlay__ {
                        status = "disabled";
                };
        };
        fragment@1 {
                target-path = "/soc/vcsm";
                __overlay__ {
                        status = "disabled";
                };
        };
};

I use the target paths here, related to /proc/device-tree/soc/fb and /proc/device-tree/soc/vcsm, but labels can be used as well, of course. There is also a kernel module, which is still tried to be loaded:

modprobe -r vc_sm_cma
echo 'blacklist vc_sm_cma' > /etc/modprobe.d/disable_vcsm.conf

What I'm still missing is an ability to completely disable composite video on RPi models prior to RPi4. There was a config.txt switch for this on older firmware versions hdmi_ignore_composite=1, which allowed, in combination with hdmi_ignore_hotplug=1, to disable the whole video stack. But that has gone with the first kernel release for RPi4.

Also to prevent some modules loaded for the RPi camera, which pull in as dependencies some others:

echo -e 'blacklist bcm2835_codec\nblacklist bcm2835_v4l2\nblacklist bcm2835_isp' > /etc/modprobe.d/disable_rpi_camera.conf

Audio and UART are disabled via dtparam=audio=off (default) and enable_uart=0, so no need to do this via overlays.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants