3

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.

Specifically:

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

3

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.

4
  • 2
    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
    Commented Oct 3, 2022 at 7:19
  • @Milliways: That's good to know - thanks for the confirmation.
    – Seamus
    Commented Oct 3, 2022 at 15:36
  • @Seamus so I assume right way is to remove dtoverlay line from config.txt to be able to switch overlays without reboots? Do they work as intended when loading and unloading with dtoverlay command on demand?
    – laimison
    Commented Jul 26, 2023 at 9:57
  • 1
    @laimison: If I understand your question, the answer is "yes"... don't place overlays in config.txt that you intend to add & remove dynamically.
    – Seamus
    Commented Jul 27, 2023 at 22:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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