Is Nix really appropriate for building a complete rootfs? Could I start from scratch and write a nix build script or whatever and end up with a rootfs I could run on some aarch64 SBC or SoM?
And how is the Nix story for going from a rootfs to a bootable image? On e.g Rockchip you need to make an image where there's some firmware blob in one are of the flash which jumps to a uBoot in another area which loads the kernel/initramfs/devicetree, how does that look in Nix land?
How does it handle building vendor kernels or carrying kernel patches instead of mainline?
I don't really like Nix but it's probably fine for this - you have files that come in, a build step, and output files. Your derivations (build recipes) are functions that can take arguments to e.g. provide a set of patches to apply. There are recipes for building a kernel in nixpkgs already which you could fork.
The main annoyance I'd have in your case is probably the number of file copies of large images it may do to keep things isolated, but most hermetic build systems will do something similar.
I mean "input files, a build step, output files" is the trivial part of this. I've made my own build systems which work the same way, it's not especially hard. But if you wanted to use my build system to make a Linux rootfs you'd find that to be a monumental effort since you'd have to do everything yourself.
It's everything built around the build script language that's relevant. How easy is it to make a Nix config which produces a rootfs with systemd, glibc, coreutils, an OpenSSL server, pam, a dbus broker, the necessary getty services, etc etc etc which makes it a Linux system? That's the question I'm asking.
Yes, most of this is all supported. There is a existing recipe for building an image that you just dd to and SD card and can boot in a Raspberry Pi (and other devices supported by mainline kernel + u-boot).
Kernel is a package just like another; so you just write your own recipe. Patching kernel recipe works just like patching any Nix recipe.
Not sure about the rockchip-proprietary boot parts; you may be on your own.
The huge boon of Yocto is that it solves the Rockchip-proprietary parts. And the Qualcomm-proprietary parts. And the IMX-proprietary parts. It has BSP layers which you can add, you can use either e.g Rockchip's official Yocto BSP which focuses on doing things their way + using a vendor kernel or you can use the Yocto project's community Rockchip BSP which focuses on doing things the Yocto way + using upstream.
Even devices which are supported by mainline Linux + uBoot have their own ways you have to do e.g partitioning or what needs to be in Flash. Lots of Rockchip devices are perfectly supported upstream, but their boot process expects to find a tiny loader at a particular flash offset which can then jump to uBoot. Nothing in the ARM SBC world is standardized so everyone does things like this (tho some have partitioning schemes you need to follow instead of using offsets). That's stuff you can't really ignore if you want to be relevant in this space.
amelius · · focus · HN ↗
mort96 · · focus · HN ↗
And how is the Nix story for going from a rootfs to a bootable image? On e.g Rockchip you need to make an image where there's some firmware blob in one are of the flash which jumps to a uBoot in another area which loads the kernel/initramfs/devicetree, how does that look in Nix land?
How does it handle building vendor kernels or carrying kernel patches instead of mainline?
aidanhs · · focus · HN ↗
The main annoyance I'd have in your case is probably the number of file copies of large images it may do to keep things isolated, but most hermetic build systems will do something similar.
mort96 · · focus · HN ↗
It's everything built around the build script language that's relevant. How easy is it to make a Nix config which produces a rootfs with systemd, glibc, coreutils, an OpenSSL server, pam, a dbus broker, the necessary getty services, etc etc etc which makes it a Linux system? That's the question I'm asking.
dezgeg · · focus · HN ↗
Kernel is a package just like another; so you just write your own recipe. Patching kernel recipe works just like patching any Nix recipe.
Not sure about the rockchip-proprietary boot parts; you may be on your own.
mort96 · · focus · HN ↗
Even devices which are supported by mainline Linux + uBoot have their own ways you have to do e.g partitioning or what needs to be in Flash. Lots of Rockchip devices are perfectly supported upstream, but their boot process expects to find a tiny loader at a particular flash offset which can then jump to uBoot. Nothing in the ARM SBC world is standardized so everyone does things like this (tho some have partitioning schemes you need to follow instead of using offsets). That's stuff you can't really ignore if you want to be relevant in this space.