Skip to content
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
wants to merge 2 commits into from

Conversation

wmanley
Copy link
Member

@wmanley wmanley commented Jan 12, 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.

Note: if #1404 is merged before this this PR will have to be updated - and vice-versa.

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
@cgwalters
Copy link
Member

Looks like the test count needs tweaking:

ERROR: tests/test-no-initramfs.sh 8 switching to bootdir with no initramfs layout=/boot # UNPLANNED
ERROR: tests/test-no-initramfs.sh 9 switching from no initramfs to initramfs enabled sysroot layout=/boot # UNPLANNED
ERROR: tests/test-no-initramfs.sh 10 switching from initramfs to no initramfs sysroot with devicetree layout=/boot # UNPLANNED
ERROR: tests/test-no-initramfs.sh - too many tests run (expected 7, got 10)

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.
@wmanley
Copy link
Member Author

wmanley commented Jan 16, 2018

I've done a git commit --amend && git push --force-with-lease to force the tests to rerun. They seemed to have hanged.

@cgwalters
Copy link
Member

Nice, thanks a lot!

@rh-atomic-bot r+ cf1b8de

@rh-atomic-bot
Copy link

⚡ 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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants