-
Notifications
You must be signed in to change notification settings - Fork 290
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
Add support for devicetree files alongside the kernel and initramfs #1411
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The bootloader spec says: > `devicetree` refers to the binary device tree to use when executing the > kernel. This also shall be a path relative to the `$BOOT` directory. This > key is optional. Example: > `6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.armv7hl/tegra20-paz00.dtb` This is necessary for booting my NVidia Tegra TK1 device. It uses u-boot with syslinux compatibility. In the syslinux files that come with the device this is called `FDT`, but u-boot treats `FDT and `DEVICETREE` as synonyms. See also: [f43c401 in u-boot]. [f43c401 in u-boot]: http://git.denx.de/?p=u-boot.git;a=commit;h=f43c401b72bb0db43ab0b55c4a79e1f4889d3aa2
Looks like the test count needs tweaking:
Otherwise looks pretty good to me! |
Much like the (optional) initramfs at `/usr/lib/ostree-boot/initramfs-<SHA256>` or `/usr/lib/modules/$kver/initramfs` you can now optionally include a flattened devicetree (.dtb) file alongside the kernel at `/usr/lib/ostree-boot/devicetree-<SHA256>` or `/usr/lib/modules/$kver/devicetree`. This is useful for embedded ARM systems which need the devicetree file loaded by the bootloader for the kernel to discover and initialise hardware. See https://en.wikipedia.org/wiki/Device_tree for more information. This patch was mostly produced by copy-pasting code for initramfs handling and renaming `s/initramfs/devicetree/g`. It's not beautiful, but it is fairly straightforward. It may be useful to extend device-tree support in a number ways in the future. Device trees dependant on many details of the hardware they support. This makes them unlike kernels, which may support many different hardware variants as long as the instruction-set matches. This means that a ostree tree created with a device-tree in this manner will only boot on a single model of hardware. This is sufficient for my purposes, but may not be for others'. I've tested this on my NVidia Tegra TK1 device which has u-boot running in syslinux-compatible mode.
I've done a |
Nice, thanks a lot! |
⚡ Test exempted: merge already tested. |
rh-atomic-bot
pushed a commit
that referenced
this pull request
Jan 16, 2018
Much like the (optional) initramfs at `/usr/lib/ostree-boot/initramfs-<SHA256>` or `/usr/lib/modules/$kver/initramfs` you can now optionally include a flattened devicetree (.dtb) file alongside the kernel at `/usr/lib/ostree-boot/devicetree-<SHA256>` or `/usr/lib/modules/$kver/devicetree`. This is useful for embedded ARM systems which need the devicetree file loaded by the bootloader for the kernel to discover and initialise hardware. See https://en.wikipedia.org/wiki/Device_tree for more information. This patch was mostly produced by copy-pasting code for initramfs handling and renaming `s/initramfs/devicetree/g`. It's not beautiful, but it is fairly straightforward. It may be useful to extend device-tree support in a number ways in the future. Device trees dependant on many details of the hardware they support. This makes them unlike kernels, which may support many different hardware variants as long as the instruction-set matches. This means that a ostree tree created with a device-tree in this manner will only boot on a single model of hardware. This is sufficient for my purposes, but may not be for others'. I've tested this on my NVidia Tegra TK1 device which has u-boot running in syslinux-compatible mode. Closes: #1411 Approved by: cgwalters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Much like the (optional) initramfs at
/usr/lib/ostree-boot/initramfs-<SHA256>
or/usr/lib/modules/$kver/initramfs
you can now optionally include a flattened devicetree (.dtb) file alongside the kernel at/usr/lib/ostree-boot/devicetree-<SHA256>
or/usr/lib/modules/$kver/devicetree
.This is useful for embedded ARM systems which need the devicetree file
loaded by the bootloader for the kernel to discover and initialise
hardware. See https://en.wikipedia.org/wiki/Device_tree for more
information.
This patch was mostly produced by copy-pasting code for initramfs handling
and renaming
s/initramfs/devicetree/g
. It's not beautiful, but it isfairly straightforward.
It may be useful to extend device-tree support in a number ways in the
future. Device trees dependant on many details of the hardware they
support. This makes them unlike kernels, which may support many different
hardware variants as long as the instruction-set matches. This means that
a ostree tree created with a device-tree in this manner will only boot on
a single model of hardware. This is sufficient for my purposes, but may
not be for others'.
I've tested this on my NVidia Tegra TK1 device which has u-boot running
in syslinux-compatible mode.
Note: if #1404 is merged before this this PR will have to be updated - and vice-versa.