WIP: Add developer options and tooling for Jetson Orin devices#17
Draft
samueldr-at-cyberus wants to merge 30 commits into
Draft
WIP: Add developer options and tooling for Jetson Orin devices#17samueldr-at-cyberus wants to merge 30 commits into
samueldr-at-cyberus wants to merge 30 commits into
Conversation
With the previous state of the module, simply adding the CTRL-OS modules to a NixOS configuration would enable the `easyCerts` system configuration and the `imageRegistry` service. Modules should strive to be no-op by default. The fix is to make the `default` rely on the state of the `services.scl-singlenode.enable` option, since the intent was, AFAICT, to enable those services by default when that option is enabled. Note that using `mkIf (cfg.enable && cfg.easyCerts)` would *work*. At least superficially. This would come with the drawback that it would be impossible to enable those options without enabling the whole `scl-singlenode` option. It might not apply to those options, but *generally speaking*, it is an antipattern, as it couples those tightly with the *implementation* of the service. It then becomes impossible for end-users, whatever their needs are, to enable those options individually. This was checked using a yet-to-be-committed check for no-op correctness of the modules system. Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
This expression checks that, as much as it can check, the evaluations of the modules system are equivalent with added modules. This is important when producing modules to import arbitrarily in your config, as they shouldn't change the behaviour of your system until they are enabled. Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
The "profiles" modules will each have a global option to enable all the opinionated options, and sub-options to make it possible for opting-in or opting-out of the opinionated settings. While it looks redundant to have the `developer` profile simply mirror the `ctrl-os-system` profile, the intent is that the developer system may enable options that are irrelevant on an "target" system. For example, udev configuration to work with USB download mode for target hardware devices. Conversely, later down the line it may make sense to enable options for the target systems that a developer generally wouldn't want. For now, we're re-using the ctrl-os-system options as it makes more sense to implement them there, since the installed systems *should* have that profile enabled to work as designed.
We can't do that. Plain and simple. Already the hardware support is not following that model, and the new profiles aren't either. This is even more important when thinking about future-proofing the "API" of our modules: we don't want tons and tons of options at the root, it makes for a messy user experience. Instead, broader scopes for modules should be defined, and those scopes define the options that make sense for them.
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
The device name (even though the vendor does not seem to always spell it out), includes “Super”. I'm using the fact that the innate DeviceTree for the platform uses the model name: ``` NVIDIA Jetson Orin Nano Engineering Reference Developer Kit Super ``` The `compatible` is `nvidia,p3768-0000+p3767-0005-super`. For this reason, we shall always use “super”. Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
This will ensure the `mkIf` conditional is always *coherent* with what it should be. Otherwise, copy/paste mistakes can become awkward to debug. Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
This is the first part of a change set that mirrors a commit from Julian. This only *moves* the files and module itself around, the options names are changed in the follow-up commit. Co-authored-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
This is the final part of a change set that mirrors a commit from Julian. This one renames the options from platform to hardware devices, better future-proofing the options. This also has the benefit of not re-using a term (platform) that has an existing meaning with Nixpkgs things (`stdenv.hostPlatform.system`), and should make it less confusing to discuss about. Co-authored-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
This is WIP because this is currently using the `legacyPackages` Flake output attribute, but I believe this is the wrong thing to do. These are not packages, they would not be added to a user's system. The `flakeModule` design seems to break down once you need something that isn't in the "well-known"[sic] outputs of Flakes.
samueldr-at-cyberus
force-pushed
the
feature/devtools-jetson
branch
from
49f2247 to
75deda5
Compare
Signed-off-by: Samuel Dionne-Riel <samuel.dionne-riel@cyberus-technology.de>
These modules are for the *developer systems*, not for the target systems. They are meant to hold either necessary or helpful system-wide configuration for working with target devices. Noting that we should prefer *not* installing system-wide packages for tools and such by default, and mainly ensure that the system-wide configuration is proper. The rationale being that the exact tooling should be part of a developer shell for the target devices, rather than installed system-wide. Especially true when some targets may require tooling of older/newer versions than others, and may need to be worked with concurrently by the developers!
Add a module that, for now, only adds the udev rules for one Tegra device (Orin). We could guess at other device identifiers by carefully searching online, but that would be untested. This udev rule was verified to work with the platform firmware flashing tooling from this repo. No root privileges required!
It's empty. It's getting contents in the follow-up commits.
This adds the Jetpack SDKs expression, maybe a bit over-engineered, but this should be an implementation detail for the follow-up steps. The licensing information should be fixed-up so it is proper for the SDK terms.
samueldr-at-cyberus
force-pushed
the
feature/devtools-jetson
branch
from
75deda5 to
e147e65
Compare
This adds a wrapper around the “bootloader”[sic] tooling that simplifies the re-installation of the platform firmware onto a Tegra system. Reflashing a system for the targets part of the vendor SDK should be as simple as calling the wrapper with the appropriate target name. ``` reflash-bios $target ``` The `reflash-bios` script will list the available targets when called without an argument. That is, assuming that proper access is given so the USB device can be communicated with, either through udev rules, or via superuser privileges. The script mainly focuses on dropping anything related to flashing the operating system, and flashing ***only*** the platform firmware. Doing so enables the script to run without root privileges (the scripts are kinda scary and try to do a lot of image manipulation). With Flakes, the tool can be (currently) launched using: ``` export NIXPKGS_ALLOW_UNFREE=1 nix run --impure .#hardware.nvidia.tegra.developer-tools.orin.platform-firmware-tooling ```
samueldr-at-cyberus
force-pushed
the
feature/devtools-jetson
branch
from
e147e65 to
8e9fbb7
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
(Builds on top of #16)
This diff view will be easier to work with.
This is super WIP, but is intended to be part of the broader discussion surrounding the structure of the project.
TODO
meta.licensesappropriately