Move devicePkgs to the pkgs.nvidia-jetpack package-set and clear up...
#206
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
jmbaur
force-pushed
the
device-pkgs-to-overlay
branch
from
227f421 to
a005de7
Compare
|
Can you try building a NixOS system with Also, do you expect this PR to not change flash/fuse script and NixOS system hashes? |
jmbaur
force-pushed
the
device-pkgs-to-overlay
branch
2 times, most recently
from
e755577 to
607503a
Compare
|
Just pushed a change that does allow for |
jmbaur
force-pushed
the
device-pkgs-to-overlay
branch
from
607503a to
c7a4a4c
Compare
|
I do not expect the output hashes to be the same, although the nix-diff between the two do not show many differences. For example, here's the nix-diff for the flake output |
jmbaur
force-pushed
the
device-pkgs-to-overlay
branch
8 times, most recently
from
236b427 to
882ff14
Compare
jmbaur
force-pushed
the
device-pkgs-to-overlay
branch
from
882ff14 to
9f54678
Compare
jmbaur
force-pushed
the
device-pkgs-to-overlay
branch
2 times, most recently
from
ebd2266 to
f1ed411
Compare
jonringer
reviewed
Jun 14, 2024
jonringer
approved these changes
Jun 14, 2024
|
There are two major components to this PR that by being combined make this difficult to both review and want to merge simultaneously.
I'm still skeptical that this is an approach we want to take. I'd be happy to provide an option to apply an overlay to the device packages set, if that helps, but it doesn't seem right to have the overall package set depend on the NixOS configuration to that extent. If anything, I'd like to have the flashing scripts, firmware, etc be able to be built without evaling an entire NixOS system. Given the goals of UEFI platform firmware, I'd like to allow people to build and flash platform firmware from this repo and then install not-NixOS on it. (e.g. Ubuntu/Redhat, etc)
This part is uncontroversial and I'd be happy to merge, assuming the weird stuff we do with qemu on aarch64 to make signedFirmware still work. If you open a PR that does just this part I think it'll be easier for me to merge. |
ambiguities with systems compatible for flash/fuse scripts Instead of maintaining a separate package-set location (outside of `pkgs`), we can just use regular overlays to apply our changes that are device-specific (stored under the `pkgs.nvidia-jetpack` scope). An alias is added to the old locations (`config.system.build.jetsonDevicePkgs`, `config.hardware.nvidia-jetpack.devicePkgs`, etc.) with a warning to indicate that users should just use `pkgs.nvidia-jetpack`. Also included is clearing up the ambiguities of what systems are compatible with flash/fuse scripts. NVIDIA makes the decision for us as to what platforms we can run these tools on (x86_64-linux only), so we shouldn't allow for any flash/fuse derivations to be built for aarch64-linux. The rundown: - a jetson device nixos config's `hostPlatform` _must_ be `aarch64-linux` - a flash/fuse script's `hostPlatform` _must_ be `x86_64-linux` What we were doing before was mixing package-sets willy-nilly without much control over which hostPlatform we were dealing with (leading to lots of usage of hardcoded `pkgsAarch64` to force a package-set to aarch64). This change makes a logical separation of what needs to be built with an aarch64 hostPlatform package-set vs an x86_64 hostPlatform package-set.
jmbaur
force-pushed
the
device-pkgs-to-overlay
branch
from
f1ed411 to
29e6cea
Compare
Why would we not want to reuse the option that already exists for such behavior ( edit: In the example of building the EDK2 firmware, doing it anyway that isn't similar to the way I just mentioned ends up being troublesome for a few different reasons:
Of course the way I mentioned above is not convenient, the attribute path is quite long, but this can of course be made more convenient by dropping it under |
|
While I'd still like to not apply nixpkgs overlays dependent on NixOS config, and not require evaling NixOS to create flash scripts, I did a prototype implementation over the weekend of restructuring this in the way I would prefer, and at least on initial benchmarks, my proposed implementation did not noticeably improve eval time compared to this PR. With that in mind, I think we can proceed with this in the meantime, as it is a correctness improvement over the current Nix code since it uses a pkgs import for the flasher machine which should always match the correct architecture. |
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.
...ambiguities with systems compatible for flash/fuse scripts
Description of changes
Instead of maintaining a separate package-set location (outside of
pkgs), we can just use regular overlays to apply our changes that are device-specific (stored under thepkgs.nvidia-jetpackscope). An alias is added to the old locations (config.system.build.jetsonDevicePkgs,config.hardware.nvidia-jetpack.devicePkgs, etc.) with a warning to indicate that users should just usepkgs.nvidia-jetpack.Also included is clearing up the ambiguities of what systems are compatible with flash/fuse scripts. NVIDIA makes the decision for us as to what platforms we can run these tools on (x86_64-linux only), so we shouldn't allow for any flash/fuse derivations to be built for aarch64-linux.
The rundown:
hostPlatformmust beaarch64-linuxhostPlatformmust bex86_64-linuxWhat we were doing before was mixing package-sets willy-nilly without much control over which hostPlatform we were dealing with (leading to lots of usage of hardcoded
pkgsAarch64to force a package-set to aarch64). This change makes a logical separation of what needs to be built with an aarch64 hostPlatform package-set vs an x86_64 hostPlatform package-set.Testing
Tested building and running flash script and initrd flash script for an orin-agx-devkit