raspberrypi-eeprom: Init at 2020-10-05 #88825
Conversation
dasJ
force-pushed
the
init/rpi-eeprom
branch
2 times, most recently
from
9873e78
to
a10fccb
Compare
| wrapProgram $out/bin/rpi-eeprom-update \ | ||
| --set FIRMWARE_ROOT $out/share/rpi-eeprom \ | ||
| --set VCMAILBOX ${raspberrypi-tools}/bin/vcmailbox \ | ||
| --prefix PATH : "${lib.makeBinPath [ binutils-unwrapped findutils kmod pciutils raspberrypi-tools (placeholder "out") ]}" |
There was a problem hiding this comment.
it may help to omit raspberrypi-tools, vl805 and maybe rpi-eeprom-update when targeting x86, since the rpi-eeprom-config script still works on x86, and is useful to have there
There was a problem hiding this comment.
How is rpi-eeprom-config useful on x86? What's the use-case?
| version = "unstable-2020-05-15"; # USB boot on the beta channel | ||
|
|
||
| src = fetchFromGitHub { | ||
| owner = "raspberrypi"; | ||
| repo = "rpi-eeprom"; | ||
| rev = "ad18a5b468f787ed37ab62e0a699dabeaa580e27"; | ||
| sha256 = "sha256-E+Fq7VO+gLbCVAawuYfYxBFGER6nelgR8EHwSnc37GQ="; | ||
| }; |
There was a problem hiding this comment.
I believe we should follow the stable (critical?) channel by default, but most likely we also want to provide a trivial-to-use way to use beta; I'm not sure if it's common to provide an attribute to the derivation like betaChannel and change the source on that attribute.
Though, we should follow the stable channel, that is for sure, we can't have a beta update slip on user's systems if they don't want it.
There was a problem hiding this comment.
the channels on the eeprom are a bit confusing
the latest version for each channel is all in a single git repo, at the same time, with slightly confusing names
i think the one in critical on master, is considered stable and safe for use by anybody
There was a problem hiding this comment.
I see... this could get confusing fast.
I would recommend not putting that comment about USB boot, though possibly a comment stating that we are following the tip of master, which does not mean that the firmware files are unstable.
Though, at the current time, it seems using a tagged release is possible, and might be preferred still, if only to better communicate what is being used?
v2020.05.28-137ad is basically the tip, except for a small QOL change in the eeprom script.
|
@cleverca22 @samueldr Is it better this way? |
dasJ
changed the title
Motivation for this change
cc @cleverca22
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)