Skip to content
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-bootloader: allow custom target directory and support 64-bit Raspberry Pi 3 #47250

Closed

Conversation

lopsided98
Copy link
Contributor

Motivation for this change

This PR is the collection of changes needed to get my Raspberry Pis to boot in the variety of configurations I use. I needed to be able to generate SD card images for Pi Zeroes that used the RPi bootloader without U-Boot (to support DT overlays), and a Pi 1 using U-Boot. I also needed to support the Raspberry Pi 3 in 64-bit mode w/o U-Boot (again for DT overlays).

Things done

I refactored (and renamed) the RPi bootloader builder scripts to be more like the generic-extlinux-compatible builder. They now take an argument specifying the target directory, allowing them to be used in sdImage.populateBootCommands. For the RPi bootloader builder, I had to change the logic a bit to allow writing a default generation when there were no generations in the system profile (when building an SD card image). The changes to the U-Boot builder should make it possible to use boot.loader.raspberryPi.uboot instead of boot.loader.generic-extlinux-compatible in the NixOS SD images, but this PR does not do that. See here for an example of how I generate SD card images for my Pi Zeroes.

This PR also allows a 64-bit kernel to be booted on the Pi 3 without U-Boot. The problem was that the kernel was written to /boot/kernel7.img, while the Pi was looking for kernel8.img. This PR causes the kernel to always be written to kernel.img and adds a line to config.txt explicitly specifying that location. I also had to copy the device trees from the correct location in the 64 bit kernel.

While I was at it, I also added 0 as a allowable value for boot.loader.raspberryPi.version which causes the correct U-Boot build to be used. The RPi 1 U-Boot generally works fine on the Zero, so this change isn't that important.

Some possible issues with this PR are that Pi 2 and 3 users will have unused kernel7.img files in /boot, which will take up the limited space in /boot and will have to be deleted manually. Also /boot/defaultgeneration is no longer created (because there are now files named default-{cmdline.txt,init,initrd,kernel,system} in /boot/old which serve the same purpose), but the existing file is not deleted, which might confuse users.

cc @dezgeg

  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Fits CONTRIBUTING.md.

NixOS is unable to boot using the RPi bootloader (w/o U-Boot) unless the initrd
is configured.
@lopsided98
Copy link
Contributor Author

I added a commit that configures the initrd when not using U-Boot. I have had this in my local config for a long time, but I decided to add it to this PR because, AFAIK, it is not possible to boot directly from the RPi bootloader without this line. This seems to mean that either no one uses the RPi bootloader directly, or everyone has figured out the workaround and applied it to their own config.

@lopsided98
Copy link
Contributor Author

@dezgeg Could you take a look at this when you get a chance?

@@ -1,13 +1,15 @@
{ config, pkgs, configTxt }:
{ pkgs, version, configTxt }:

let
cfg = config.boot.loader.raspberryPi;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dropped this line when applying to make it evaluate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, sorry, I had fixed this on my production branch, but I forgot to apply it to the PR.

@dezgeg
Copy link
Contributor

dezgeg commented Oct 21, 2018

Sorry for the delay, now applied in: https://git.io/fxKVd

@dezgeg dezgeg closed this Oct 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants