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
extlinux-conf-builder: expose and use base builder command, allow a custom FDT to be specified #91195
Conversation
nixos/modules/system/boot/loader/generic-extlinux-compatible/extlinux-conf-builder.sh
Outdated
Show resolved
Hide resolved
8a751f9
to
8c14ada
Compare
nixos/modules/system/boot/loader/generic-extlinux-compatible/extlinux-conf-builder.sh
Outdated
Show resolved
Hide resolved
nixos/modules/system/boot/loader/generic-extlinux-compatible/extlinux-conf-builder.sh
Show resolved
Hide resolved
d45a30f
to
ad3725e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't run the code, but the author verifiably did, successfully, and it looks all right.
hardware.deviceTree.base points to a path, not a package (and also if of types.path) It defaults to ${config.boot.kernelPackages.kernel}/dtbs.
I realized this currently only fixes half of the problem - while one would now be able to pass this to the exlinux builder, the I added the necessary option as |
ad3725e
to
7dfb841
Compare
I pushed an updated version, containing some drive-by fixes, the refactor, and the addition of the fdt option, please take another look :-) |
@@ -8,7 +8,7 @@ let | |||
|
|||
timeoutStr = if blCfg.timeout == null then "-1" else toString blCfg.timeout; | |||
|
|||
builder = import ./extlinux-conf-builder.nix { inherit pkgs; }; | |||
builder = import ./extlinux-conf-builder.nix { pkgs = pkgs.buildPackages; }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still not correct. While this now succeeds in assembling the image, switching at runtime won't work.
I feel like the one we expose for image generation should set pkgs = pkgs.buildPackages
) (and should probably be named to reflect that), but we still need to have a builderusing the native packages inside this module (as that generates the line in the activation script, which runs on the board architecture).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I renamed the option to populateCmd
, so it's usecase is clearer, and explicitly distinguished between the builder used during activation and the builder used to populate a (possibly cross) image.
I prefer this over just exposing the arguments - then every sd-image-*
would then need to still import the builder.
…inux-compatible.populateCmd This option exposes the builder command used to populate an image, honoring all options except the -c <path-to-default-configuration> argument. Useful to have for sdImage.populateRootCommands. Special care needs to be taken w.r.t cross - the populate command runs on the host platform, the activation script on the build platform (so the builders differ)
…eCmd While getting rid of the separate extlinux-conf-builder import, this now also honors boot.loader.timeout in the initial sd card image if specified.
Some bootloaders might not properly detect the model. If the specific model is known by configuration, provide a way to explicitly point to a specific dtb in the extlinux.conf.
This can be used to explicitly specify a specific dtb file, relative to the dtb base. Update the generic-extlinux-compatible module to make use of this option.
7dfb841
to
387f3b5
Compare
This now also works - I successfully switched configurations and built cross sd images with this module. PTAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't run the latest changes, but it all looks fine and I trust @flokli as having ran this correctly.
The newly added option (hardware.deviceTree.name
) may be useful in other situations too.
I....totally don't know about this stuff. But maybe the other @NixOS/exotic-platform-maintainers do and can review instead (I see you already CCed). |
Okay, let's merge this :-) |
This contains two more PRs currently staged for nixpkgs: - nixos/make-ext4-fs: increase fudge factor from 1.03 to 1.10 NixOS/nixpkgs#91214 - extlinux-conf-builder: allow a custom FDT to be specified NixOS/nixpkgs#91195 The former one is needed to have the initial sd image be big enough to be able to resize itself, the latter to circumvent u-boot not properly detecting our board, and trying to load the wrong FDT.
Some bootloaders might not properly detect the model.
If the specific model is known by configuration, provide a way to
explicitly point to a specific dtb in the extlinux.conf.
This adds
hardware.deviceTree.name
, uses it from the generic-extlinux-compatible module, and exposes the builder command generated there as a read-only NixOS option, which is now used by the sd-image-*.nix files - allowing us to get rid of all the additional imports there, too.Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)cc @NixOS/exotic-platform-maintainers