Configure the Pi firmware (Raspberry Pi)

There is no bootloader to install. The Pi’s own firmware reads a handful of files from the FAT partition at /boot, loads the kernel and initramfs itself, and jumps straight in. Everything you need is already on that partition:

ls /boot

bcm2712-d-rpi-5-b.dtb      fixup4db.dat          start4.elf
bcm2712-rpi-500.dtb        fixup4x.dat           start4cd.elf
bcm2712-rpi-5-b.dtb        fixup_cd.dat          start4db.elf
bcm2712-rpi-cm5-cm4io.dtb  fixup_db.dat          start4x.elf
bcm2712-rpi-cm5-cm5io.dtb  fixup_x.dat           start.elf
bcm2712-rpi-cm5l-cm4io.dtb initramfs-linux.img   start_cd.elf
bcm2712d0-rpi-5-b.dtb      kernel8.img           start_db.elf
bootcode.bin               overlays              start_x.elf
cmdline.txt                config.txt
fixup.dat                  fixup4.dat
fixup4cd.dat

kernel8.img is the kernel and initramfs-linux.img is the image you just built. The .dtb files are device trees – one per board, so the firmware can tell the kernel what hardware it is running on, which is why a Pi 500 and a CM5 can share one installation. The start*.elf and fixup*.dat files are the Pi’s own firmware, and overlays/ holds device-tree overlays for add-on hardware.

config.txt is already correct

config.txt is the firmware’s own configuration, and the one line that matters here is already in it:

grep initramfs /boot/config.txt

initramfs initramfs-linux.img followkernel

That is what makes the firmware load the initramfs alongside the kernel. It ships that way, so leave the file alone.

cmdline.txt is not

cmdline.txt is the kernel command line, and it ships pointing at an SD card:

cat /boot/cmdline.txt

root=/dev/mmcblk0p2 rw rootwait console=serial0,115200 console=tty1 fsck.repair=yes

Two things are wrong with that for this install: the root device is whatever disk you actually used, and there is no rootflags, so even the right device would mount the top of the btrfs filesystem rather than the @ subvolume. Replace it:

cat > /boot/cmdline.txt <<EOF
root=UUID=$(findmnt -no UUID /) rootflags=subvol=@ rw rootwait console=serial0,115200 console=tty1 fsck.repair=yes
EOF
cat /boot/cmdline.txt

rootwait is doing real work on a Pi booting from USB or NVMe: it tells the kernel to wait for the device to appear rather than giving up, and those buses can take a moment to enumerate.

If you encrypted the disk

Point the command line at the unlocked mapper device, and tell the initramfs which partition to unlock, using the LUKS partition’s UUID:

cat > /boot/cmdline.txt <<EOF
rd.luks.name=$(blkid -s UUID -o value /dev/nvme0n1p2)=cryptroot root=/dev/mapper/cryptroot rootflags=subvol=@ rw rootwait console=serial0,115200 console=tty1 fsck.repair=yes
EOF

Substitute your own root partition for /dev/nvme0n1p2.

Your edits will survive updates

Both files belong to the kernel package, which would normally mean a kernel update overwrites them. It does not, because both are declared as pacman backup files:

pacman -Qii linux-rpi-16k | grep -A2 'Backup Files'

Backup Files    : /boot/config.txt [unmodified]
                  /boot/cmdline.txt [modified]

pacman keeps a modified backup file and writes the new version alongside it as cmdline.txt.pacnew. So your boot configuration is safe, but it also means genuinely new firmware options arrive in a file you have to go and read. Check for .pacnew files after kernel updates.

With the kernel locatable and the root filesystem findable, the machine can start itself. What it cannot yet do is let you log in – there is no user account and no network configuration. That is the next chapter, and it has to be finished before the first reboot.