NixOS on ARM/UEFI: Difference between revisions
imported>Samueldr mNo edit summary |
imported>Samueldr m renamed IBF to PF; wording used in EBBR |
||
| Line 13: | Line 13: | ||
Just as you could on <tt>x86_64</tt> if your platform required it, you can build a customized iso image. Explaining this is out of scope for this article. The same pitfalls apply. For example, the generated configuration will not take into account configuring the customized kernel. | Just as you could on <tt>x86_64</tt> if your platform required it, you can build a customized iso image. Explaining this is out of scope for this article. The same pitfalls apply. For example, the generated configuration will not take into account configuring the customized kernel. | ||
=== | === Platform Firmware === | ||
Let's define what | Let's define what a '''Platform Firmware''' is. It is a generic term I'm using to describe the first thing the CPU starts at boot time. On your typical <tt>x86_64</tt> system, it would be what was previously called the ''BIOS''. Now often diminutively called by the name ''EFI''. This is what initializes enough of the hardware so that the operating system can start. Additionally, it often provides facilities for the user to do basic configuration, and manage boot options. | ||
In the ARM with SBCs landscape, '''U-Boot''' is the de facto solution for the '' | In the ARM with SBCs landscape, '''U-Boot''' is the de facto solution for the ''Platform Firmware''. Though ''U-Boot'' is confusingly, but rightly, often referred to as a ''Boot Loader''. ''U-Boot'' plays double duties often. It is tasked with ''initializing the hardware'', and often also used to handle ''loading and booting'' the operating system. | ||
=== UEFI === | === UEFI === | ||
| Line 33: | Line 33: | ||
Believe me or not, it's more likely that you can, if your SBC is well supported by mainline ''U-Boot''. ''U-Boot'' provides enough UEFI to comply with EBBR, which in turn is enough to allow us to boot the <tt>AArch64</tt> UEFI NixOS iso, and with almost no differences compared to the <tt>x86_64</tt> guide, simply follow the installation instruction to boot into an installed system. | Believe me or not, it's more likely that you can, if your SBC is well supported by mainline ''U-Boot''. ''U-Boot'' provides enough UEFI to comply with EBBR, which in turn is enough to allow us to boot the <tt>AArch64</tt> UEFI NixOS iso, and with almost no differences compared to the <tt>x86_64</tt> guide, simply follow the installation instruction to boot into an installed system. | ||
=== Getting | === Getting a ''Platform Firmware'' === | ||
{{expansion|More details and alternative ways to go would be desirable}} | {{expansion|More details and alternative ways to go would be desirable}} | ||
| Line 39: | Line 39: | ||
As an opinionated example, you can get started with [https://github.com/Tow-Boot/Tow-Boot Tow-Boot, a ''U-Boot'' distribution], which is intended to make the initial setup a bit easier by abstracting the platform differences so that they do not matter. | As an opinionated example, you can get started with [https://github.com/Tow-Boot/Tow-Boot Tow-Boot, a ''U-Boot'' distribution], which is intended to make the initial setup a bit easier by abstracting the platform differences so that they do not matter. | ||
Any other UEFI | Any other UEFI compliant ''Platform Firmware'' can be used. | ||
=== Getting the installer image === | === Getting the installer image === | ||
| Line 50: | Line 50: | ||
With the ''new kernel'' variant being preferred | With the ''new kernel'' variant being preferred | ||
This installer image should be written to a USB drive, like usual. In a pinch, it may also be written to an SD image, if your target's | This installer image should be written to a USB drive, like usual. In a pinch, it may also be written to an SD image, if your target's platform firmware does not need to be written to that same SD image. This UEFI iso is incompatible (by design) with ''shared firmware storage''. | ||
=== Installing === | === Installing === | ||
| Line 60: | Line 60: | ||
==== Shared Firmware Storage ==== | ==== Shared Firmware Storage ==== | ||
{{note|This will make more sense when ''Getting | {{note|This will make more sense when ''Getting a Platform Firmware'' is finished...}} | ||
If your ''Initial Boot Firmware'' lives on the target installation storage, e.g. written to an SD card and you install to the same SD card, you will need need to make sure that: | If your ''Initial Boot Firmware'' lives on the target installation storage, e.g. written to an SD card and you install to the same SD card, you will need need to make sure that: | ||
| Line 68: | Line 68: | ||
* To not delete required existing firmware partitions. | * To not delete required existing firmware partitions. | ||
{{note|If your '' | {{note|If your ''Platform Firmware'' is not protected by a partition, consider choosing an alternative ''Platform Firmware'' installation method or distribution that protects it.}} | ||
Otherwise, you can do as you would usually, create an ESP partition, FAT32, to be mounted at <code>/boot/</code>, your preferred rootfs partition, swap if desired, etc. | Otherwise, you can do as you would usually, create an ESP partition, FAT32, to be mounted at <code>/boot/</code>, your preferred rootfs partition, swap if desired, etc. | ||
| Line 74: | Line 74: | ||
==== Bootloader configuration ==== | ==== Bootloader configuration ==== | ||
Know if your '' | Know if your ''Platform Firmware'''s UEFI implementation has writable EFI vars. This is not true for all UEFI implementations on ARM, but is something to be mindful about. If it does not, {{Nixos:option|boot.loader.efi.canTouchEfiVariables}} has to be set to '''<code>false</code>'''. | ||
<syntaxhighlight lang="nix"> | <syntaxhighlight lang="nix"> | ||
| Line 111: | Line 111: | ||
As of right now, there is no consensus within Linux distros about the topic of managing device trees for the boot process with UEFI. | As of right now, there is no consensus within Linux distros about the topic of managing device trees for the boot process with UEFI. | ||
This current setup relies on the | This current setup relies on the platform firmware providing an appropriate device tree for the kernel that will run. | ||
With ''U-Boot'', it is possible to make it load a device tree, for example a more up-to-date one, by placing the dtb folder from a kernel build output at the <code>/dtb</code> location in the ESP. ''U-Boot'' will automatically load a device tree according to heuristics, which should be the right one. | With ''U-Boot'', it is possible to make it load a device tree, for example a more up-to-date one, by placing the dtb folder from a kernel build output at the <code>/dtb</code> location in the ESP. ''U-Boot'' will automatically load a device tree according to heuristics, which should be the right one. | ||
It is unknown how much of an actual issue this is in practice. | It is unknown how much of an actual issue this is in practice. | ||