I am working on a couple of ideas for device tree overlays for the RPi 3B+ & 4B. It will be useful in my testing to be able to load and unload overlays without having to reboot each time. As described in The Dynamic Device Tree, the dtoverlay command is able to accomplish this loading and un-loading at run time - a useful feature I think. Additional usage documentation is contained in man dtoverlay.

The documentation contains several important caveats wrt use of the dtoverlay command. I think I've respected these caveats, but dtoverlay doesn't seem to be working exactly as described in this official documentation; specifically wrt listing overlays that are in use/loaded.


dtoverlay -a and dtoverlay -l are similar. The former lists all defined overlays and places an asterisk (*) next to the ones that are loaded; the latter lists all currently loaded overlays.

Running dtoverlay -a lists all overlays, but none are shown as loaded (i.e. no * for any item in the list). Running dtoverlay -l lists nothing at all.

I know that there are several overlays loaded because: a) they are included in /boot/config.txt, and b) I can verify they are operating.

I've found that if I defer loading an overlay, both of these commands seem to work as advertised; i.e. I remove the dtoverlay from /boot/config.txt, reboot, load the overlay dynamically with sudo dtoverlay gpio-led gpio=25, then it does show up in the listings as loaded.

And so this is my question: It seems odd that dtoverlay distinguishes an overlay loaded at boot time from one that is loaded at run time. How does dtoverlay know the difference, and why does it care?

This question is similar to an older question, but that Q&A did not cover usage of the new-ish dtoverlay command.

1 Answer 1


I asked this question 6 months ago, and as I've gotten no answer I'll assume that the answer is that the dtoverlay command is incapable of accessing overlays that were loaded at boot time; i.e. the dtoverlay command deals only with overlays that are/were loaded at run time.

The documentation is ambiguous IMHO, but the following may be a clue:

an overlay or parameter applied by the firmware becomes "baked in" such that it won’t be listed by dtoverlay and can’t be removed.

Again, this strikes me as ambiguous, but if one interprets this statement to mean that the dynamic device tree is an ephemeral device tree which is separate and apart from the device tree created at boot time, then perhaps it makes a bit more sense. In other words, dtoverlay is completely ignorant of the boot time device tree. I guess the thinking was that limited runtime utility is better than none at all.

I am marking this as the "Accepted" answer for now, but will gladly change that if a definitive answer is supplied.

  • 1
    I often use dtoverlay & dtparam at run time for testing and can confirm that those loaded at boot are invisible at run time. Initially I expected that I could at least list them if not delete.
    – Milliways
    Oct 3, 2022 at 7:19
  • @Milliways: That's good to know - thanks for the confirmation.
    – Seamus
    Oct 3, 2022 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.