nixos rpi bootloader: install files for raspberry pi 4 (rpi4) #112677
Conversation
colemickens
force-pushed
the
rpi4-uboot
branch
from
d9b6c67
to
460f83e
Compare
|
One other note, my firmware is a bit ahead of what we have in nixpkgs, but the note on it requests that I update the rpi foundation kernel do, which I'm not trying to do right now. I'm hoping this doesn't matter... |
colemickens
force-pushed
the
rpi4-uboot
branch
from
460f83e
to
95b84ba
Compare
| # Add the config.txt | ||
| copyForced @configTxt@ $target/config.txt | ||
| # Add the raspberry pi 4 specific files | ||
| if [[ "@version@" == "4" ]]; then |
There was a problem hiding this comment.
this was previously wrong. I noticed since I wiped my rpi4 /boot and these files were missing afterward.
There was a problem hiding this comment.
I wonder if we shouldn't rather support all aarch64 Raspberry Pi at once.
Right now configuring for the Raspberry Pi 4 means you also get the files for the Raspberry Pi 3 family, but not the inverse. Unless I'm mistaken?
Doing so would require config.txt to be aware of the [pi_] sections I guess.
There was a problem hiding this comment.
I think your analysis is right, and the improvement you suggest would be the next/last big thing on the road to re-using this exact logic/builder for the sd-card image...
... but I can't sign-up for that right now.
colemickens
force-pushed
the
rpi4-uboot
branch
from
95b84ba
to
27b6d45
Compare
|
Alright, I've now tested this by:
And the system came back correctly. This rpi4 system boot config looks like this: boot = {
loader.grub.enable = false;
loader.raspberryPi.enable = true;
loader.raspberryPi.version = 4;
loader.raspberryPi.uboot.enable = true;
loader.raspberryPi.uboot.configurationLimit = 5;
# ...
}; |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
| else | ||
| throw "U-Boot is not yet supported on the raspberry pi 4."; | ||
| throw "U-Boot is not yet supported on the raspberry pi 5."; |
There was a problem hiding this comment.
| throw "U-Boot is not yet supported on the raspberry pi 5."; | |
| throw "U-Boot is not yet supported on the raspberry pi ${toString version}."; |
|
I have tested this on my pi4 and it does indeed boot and work nicely via the uboot loader |
|
I can also confirm this boots mainline kernel. Get the serial up and running by adding {
boot.kernelParams = [
"console=ttyS1,115200n8"
];
}Unfortunately the serial is a bit messy. Either way, it boots. Can you rebase this change, so we can merge it in time for 21.05 and update the docs, so RPi4 users can migrate to mainline? Broken serial log disappears after blacklisting |
|
@colemickens Can you rebase please? https://github.com/mohe2015/nixpkgs/tree/rpi4-uboot should be a correct rebase. Also applying the one suggestion would be great! |
|
Also is it possible to create an iso/sd image from this? And is this useful? |
|
The infra in nixpkgs for building an rpi4-capable SD Card already prepare uboot in their own way. I don't think it's a super-wise investment to try to unify the uboot setup between the two right now, for a few different reasons. |
|
Is there anything preventing this from being merged? |
|
As the author of this PR, I'm personally more interested in making Tow-Boot and a traditional UEFI installation the preferred way to install. This is messy business, I'd love to let Tow-Boot handle it all. I think @samueldr has done a lot of thinking to arrive at a good model with some fun paths to take things in if it goes well. I don't really have any opinion one way or the other about this being merged as is. |
While Tow-Boot may be the better solution long term, it is a fundamentally different approach. Unless there is a plan is to completely remove this approach, it would be good to have support for all Pi versions. @samueldr Thoughts? |
|
This PR only affects installing U-Boot files to a boot partition. This is not how the generic image was conceived to be used. NixOS should not manage the firmware used to boot itself on ARM. This is because it's unknown exactly how it was installed at the first place, and will work differently depending on the system. Supporting it for a specific class of hardware (Raspberry Pi) is only going to cause some more confusion. I believe NixOS should not manage the firmware for many reasons. The first is that the firmware should stay neutral to the operating system it intends to boot. The second, and more important, is that it is impossible to handle the firmware through generations. So a firmware update can break currently working generations, maybe even prevent the system from booting anything at all. Handling firmware updates through a different mechanism (which doesn't exist at this point) ensures a routine NixOS upgrade won't prevent the system from booting at all. In many ways, the current " On thing to realize is that right now we produce a NixOS SD image which coincidentally ships with the Raspberry Pi firmware pre-installed because it is prohibitively difficult to install it after the fact. If it wasn't, it would be like other ARM systems, "bring your own firmware". The Using any If it was just me, the The current recommendation is: If the image you are using was originally built with the If the image you are using was originally built with an unmanaged Is there anything I'm missing here? |
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
|
If anyone finds this issue. I've moved to https://github.com/pftf/RPi4 and the aarch64 installer ISO. Best decision ever. |
stale
bot
removed
the
2.status: stale
|
What's the status on this PR? I've been using on my Raspberry Pi 4 for a long time already, and it never broke since I've started using it. |
|
From a few posts back, this is still my take on this PR: #112677 (comment) I'll have an update on the more ideal solution using tow-boot in a week or two (waiting on a rpi3b to be able to test across all aarch64 rpi devices) |
|
I'll have an update on the more ideal solution using tow-boot in a week or two (waiting on a rpi3b to be able to test across all aarch64 rpi devices)
Count me in as one of the testers once you make a PR. I would gladly
test this in production, as I always do with my Raspberry Pi. After all,
thanks to NixOS and how my boot partition is structured, fixing my boot
config is just an SD card swap...
|
|
Tested on a Pi4 and without this PR it is not rebooting properly. If no one objects I would merge this in the next days. |
|
PR works well for me. I think it should even be merged into 22.05. |
|
As the author I still think that we are better off not merging this. I do
feel guilty about not having published more of my rpi/tow-boot work but my
life got turned upside down and will be hectic for a few more weeks before
I can start writing some blog posts and pushing new PRs.
…On Wed, Jun 29, 2022, 11:50 AM Astro ***@***.***> wrote:
PR works well for me. I think it should even be merged into 22.05.
—
Reply to this email directly, view it on GitHub
<#112677 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACP25EHMZ6I3LJHP3BHNUDVRSEHRANCNFSM4XNVD4JQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
We need this for our network booted Pi 4s. Tow boot/UEFI is not done by tomorrow and I don't see a reason to block this PR on that. |
|
I guess I just don't want to merge stuff and then wind up ripping it back
out after the next release given Samuel's hopes and my agreement.
But also, I've been trying to push this through for a while and life
complications keep arising, so I understand wanting it merged (or carrying
it but again, I get it).
So slight "ehhh" from me but not in a "you shouldn't merge this" way.
…On Thu, Jun 30, 2022, 7:50 AM Sandro ***@***.***> wrote:
We need this for our network booted Pi 4s. Tow boot/UEFI is not done by
tomorrow and I don't see a reason to block this PR on that.
—
Reply to this email directly, view it on GitHub
<#112677 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACP25BDWS2NDWRD3HC3SEDVRWQZLANCNFSM4XNVD4JQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
The Anyway, if they're network booted, then the |
How else should you boot then?
yeah, slight misunderstanding. We are using it for the one Pi we have that is not networking booting. All others are networking booting and don't require this.
If you find the time and get to it. |
The platform firmware (stock U-Boot) is already present in the SD images. This module is not used to build the SD images. Deleting this whole set of option wouldn't break any correctly configured AArch64 Raspberry Pi system installed since ~19.09. One issue though is that end-users (through documentation lack/faults) may have misconfigured modern systems. The correct bootloader configuration to use is |
|
When I installed the RPi4 with a NixOS 21.05 image and subsequently updated the kernel, I was in need of a new U-boot (#139865 iirc) which that configuration would have brought. I am afraid that this could happen again. |
|
I agree that a solution has to be provided for that issue, but this is not it. The I do not know what the proper solution for handling platform firmware (U-Boot) updates is. It should not be tied to the NixOS generations lifecycle, as it cannot fulfill the guarantees from it. |
stale
bot
added
the
2.status: stale
|
abandoning, I've given on SBCs for now. |
stale
bot
removed
the
2.status: stale
Motivation for this change
NixOS currently has a few bootloader "builders":
The
raspberrypioption, itself, has multiple different bootloader builders that you choose from:olddir with old generation kernel/initrdgeneric-extlinux-compatiblebootloader builder which in turn drops extlinux-compatible files and dir structures.The u-boot scenario is more ideal because the user has a chance to choose a different generation to boot, including kernel and initrd. Without u-boot, the user must manually intervene and edit the sd card to switch to an old generation.
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)