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
Device tree overlays in boot loader specification #13537
Comments
Hmm id like to simplify that: cant it just be the same key for the board dtb and the overlays? Just have the first one be the board dtb and all other ones overlay in order? Definitely makes sense to have. Could you prep a change to the spec as PR maybe? |
Device tree overlays are a convenient way to patch device trees, e.g., add new devices to a device tree or enable/disable devices. This is useful for non-discoverable but configurable hardware. Device tree overlays are commonly used for displays on the Raspberry Pi or for describing the content of FPGA bitstreams. Add the devicetree-overlay key to boot loader specification entries to allow boot loaders to apply overlays. See systemd#13537
This sounds like a nice simplification, but is not backwards compatible. Until now, a boot loader could safely assume that the value of the device tree key refers to exactly one file containing a device tree blob. If we change the spec that the device tree key can contain a list of files instead of a single file, this assumption does not hold anymore and any old boot loader will not be able to load a device tree if it encounters a boot entry that follows the new spec. If we introduce a new key, the old boot loader will simply ignore the overlay key and at least boot the system.
I opened #13801 |
Device tree overlays are a convenient way to patch device trees, e.g., add new devices to a device tree or enable/disable devices. This is useful for non-discoverable but configurable hardware. Device tree overlays are commonly used for displays on the Raspberry Pi or for describing the content of FPGA bitstreams. Add the devicetree-overlay key to boot loader specification entries to allow boot loaders to apply overlays. See #13537
Fixed in #13801. |
Device tree overlays are a convenient way to patch device trees, e.g., add new devices to a device tree or enable/disable devices. This is useful for non-discoverable but configurable hardware. Device tree overlays are commonly used for displays on the Raspberry Pi or for describing the content of FPGA bitstreams. Add the devicetree-overlay key to boot loader specification entries to allow boot loaders to apply overlays. See systemd/systemd#13537
Device tree overlays are a convenient way to patch device trees, e.g., add new devices to a device tree or enable/disable devices. This is useful for non-discoverable but configurable hardware. Device tree overlays are commonly used for displays on the Raspberry Pi or for describing the content of FPGA bitstreams. Add the devicetree-overlay key to boot loader specification entries to allow boot loaders to apply overlays. See systemd/systemd#13537
Is your feature request related to a problem? Please describe.
Device tree overlays are a convenient way to patch device trees, e.g., add new devices to a device tree or enable/disable devices. This is useful for non-discoverable but configurable hardware. Device tree overlays are commonly used for displays on the Raspberry Pi or for describing the content of FPGA bitstreams.
Because I want to pass the final device tree to Linux, a boot loader should be able to patch the device tree before passing the device tree to Linux. Therefore, I need a way to tell the boot loader which overlays to apply to the device tree.
Describe the solution you'd like
The configuration snippets already contain the device tree that shall be passed to Linux. Therefore, I would like to add a new key to the snippets to specify the overlays that shall be applied to the device tree before it is passed to Linux.
Describe alternatives you've considered
On Raspberry Pi, the overlays are specified using the
dtoverlay
key in the /boot/config.txt. The config.txt contains a new entry for each overlay instead of a single entry. Handling multiple overlays is a bit tricky. Since order of how the overlays are applied is important, I opted for a single key with a list of overlays.The text was updated successfully, but these errors were encountered: