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
raspberrypi-uboot: Init #38342
raspberrypi-uboot: Init #38342
Conversation
@bachp fyi. |
#! @bash@/bin/sh -e | ||
|
||
# Delete old boot folder content | ||
rm -rf /boot/* |
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.
Oh, that looks a bit scary. Can you make updating the boot files a bit more "atomic". (Disclaimer: I haven't looked at how other raspi distros do this.)
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.
Yeah, I also thought about that. I could first write all the files to a temporary directory and then swap these directories. Or do you have any better idea.
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.
If that works, perfect. But /boot might be a mountpoint, right? That may complicate things.
I don't have a concrete idea. However, one I'd like to say that perhaps a trap can be used for some added robustness. For example, if the original files are first moved to a .bak directory, and the trap restores from .bak in case of error.
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.
Why not move the old files to /boot/old
or similar like it is done in raspberrypi loader?
One general note. Wouldn't it be possible to add this to the existing raspberry pi loader? There seems to be a lot of duplication. I was thinking that updating u-boot could just be an option that can be disabled so behavior would be similar as it is now. |
f49357c
to
883fe67
Compare
@bkchr This module is working for me. 👍 However I still think this might be better done as an extension to the existing module rather than a new one. |
|
||
# Prevent the firmware from smashing the framebuffer setup done by the mainline kernel | ||
# when attempting to show low-voltage or overtemperature warnings. | ||
avoid_warnings=1 |
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.
It would be nice to be able to change the content of the config.txt
via the module option.
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.
Yeah, I already thought about that and will integrate that also.
@bachp yeah I will integrate it into the existing module. |
c0a7393
to
540ffe3
Compare
I moved the stuff back into the original I'm also still planing to integrate modification of the |
fa12804
to
fc67009
Compare
Okay, I'm finished. @dezgeg are you also responsible for this? |
{ config, pkgs }: | ||
|
||
let | ||
is64bit = pkgs.stdenv.is64bit; |
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 think conventionally stdenv.isAarch64
would be better.
cfg = config.boot.loader.raspberryPi; | ||
|
||
uboot = | ||
if cfg.version == 2 then |
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.
What about version 1?
''; | ||
}; | ||
|
||
startx = mkOption { |
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 think a generic solution to set any possible configuration option would be better instead of just these two. E.g. either make it an option set like:
boot.loader.raspberryPi.firmwareConfig = { start_x = 1; arm_freq = 950; }
or just as plain text:
boot.loader.raspberryPi.firmwareConfig = ''
arm_freq=950
'';
else | ||
pkgs.ubootRaspberryPi3_32bit | ||
else | ||
throw ("raspberrypi-uboot: unknown version: " ++ cfg.version); |
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.
In NixOS configurations, throw shouldn't be used to validate stuff but the assertions
option.
@@ -5,7 +5,7 @@ with lib; | |||
let | |||
cfg = config.boot.loader.raspberryPi; | |||
|
|||
builder = pkgs.substituteAll { | |||
builder_generic = pkgs.substituteAll { |
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.
The naming convention is camelCase, i.e. builderGeneric
.
07eefa7
to
c7e6ff7
Compare
Uboot is copied into `/boot` in the installation process. The boot entries are created by calling the `generic-extlinux-compatible` builder.
The `firmwareConfig` option will be appended to `/boot/config.txt`.
c7e6ff7
to
5a2aea0
Compare
@dezgeg I addressed your comments :) |
Sorry this took so long. I tested this on my Pi 1 and on a Pi 3, seems to work fine. |
@dezgeg np, ty :) |
Adds a bootloader for raspberry pi that uses uboot and also handles the
raspberrry pi firmware. The firmware and uboot are copied into
/boot
in the installation process. The boot entries are created by calling
the
generic-extlinux-compatible
builder.Motivation for this change
Things done
build-use-sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)