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

UKI: document the case of multiple Device Trees #71

Merged
merged 1 commit into from Oct 4, 2023

Conversation

diogo-ivo
Copy link

In connection with the discussion in 1 this pull request specifies how the case of multiple Device Trees is to be handled by choosing to append all additional Device Trees in the same .dtb section.

@@ -48,7 +48,7 @@ UKIs consist of the following resources:
* Optionally, information describing the OS this kernel is intended for, in the `.osrel` section. The contents of this section are derived from `/etc/os-release` of the target OS. They can be useful for presentation of the UKI in the boot loader menu, and ordering it against other entries using the included version information.
* Optionally, information describing kernel release information (i.e. `uname -r` output) in the `.uname` section. This is also useful for presentation of the UKI in the boot loader menu, and ordering it against other entries.
* Optionally, a splash image to bring to screen before transitioning into the Linux kernel, in the `.splash` section.
* Optionally, a compiled Devicetree database file, for systems which need it, in the `.dtb` section.
* Optionally, one or more compiled Device Trees, for systems which need it, each in its separate `.dtb` section.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a sentence after this itemized list that says something like this:

"Note that all of the sections defined above are singletons: they may appear once at most – except for the .dtb section which may be appear more than once."

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, this should say what it means if multiple .dtb sections exist. i.e. that one is picked according to some rule of picking the most appropriate one. I wouldn't define what the algorithm to pick it is, but it certainly deserves mention that only one is picked, and not all.

@jluebbe
Copy link

jluebbe commented Sep 12, 2023

Where would the selection algorithm live? In the stub which is part of the UKI?

Which would be available to make the selection? From the DT perspective, there's there top-level compatible, which declares which "boards" are compatible with this DTB, for example compatible = "beagle,am625-beagleplay", "ti,am625";. So given beagle,am625-beagleplay, the algorithm could select the correct DTB.

By searching through this list, compatible string changes can also be accomodated.

@diogo-ivo
Copy link
Author

As of now the selection algorithm is in the stub, and it just tries to match the first compatible in both the UKI FDTs and the firmware provided one. However I do agree that it would be useful to search through the lists and match that way. If others feel the same way then I can implement it in the stub

@@ -48,11 +48,13 @@ UKIs consist of the following resources:
* Optionally, information describing the OS this kernel is intended for, in the `.osrel` section. The contents of this section are derived from `/etc/os-release` of the target OS. They can be useful for presentation of the UKI in the boot loader menu, and ordering it against other entries using the included version information.
* Optionally, information describing kernel release information (i.e. `uname -r` output) in the `.uname` section. This is also useful for presentation of the UKI in the boot loader menu, and ordering it against other entries.
* Optionally, a splash image to bring to screen before transitioning into the Linux kernel, in the `.splash` section.
* Optionally, a compiled Devicetree database file, for systems which need it, in the `.dtb` section.
* Optionally, one or more compiled Device Trees, for systems which need it, each in its separate `.dtb` section. If multiple .dtb sections exist then one of them is selected according to an implementation specific algorithm.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"implementation-specific" (with dash).

* Optionally, the public part of a public-private key pair in PEM format used to sign the image, in the `.pcrpkey` section.
* Optionally, a signature made using the abovementioned key pair, in the `.pcrsig` section.
* Optionally, a JSON file encoding expected PCR 11 hash values seen from userspace once the UKI has booted up, along with signatures of these expected PCR 11 hash values, in the `.pcrsig` section. The signatures must also match the abovementioned key pair.

Note that all of the sections defined above are singletons: they may appear once at most – except for the .dtb section which may be appear more than once.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Backticks around .dtb.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the review comments, I have addressed these points in the updated push

Specify how the case of multiple Device Trees is to be handled.
@keszybz keszybz merged commit 5fab44a into uapi-group:main Oct 4, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants