Finish stage-0 boot features

[samueldr]

We were left with the following issues to deal with:

• Fixes stage-0: Use generation's .dtb as kexec --dtb parameter #264
• Fixes stage-0: Add "Keep stage-0 kernel" option to generation selection GUI #266

This PR implements both features.

---

Skip generation kernel

It is possible to continue booting with the kernel used to boot the stage-0 bootloader. It will be useful for the three following scenarios:

• Validating kexec did not cause an issue with the booted system
• Recovering a system where none of the generation kernels boot properly
• Testing a kernel build without making a generation

---

Use generation DTB

Self-explanatory... Or is it?

Each generation could have their own DTB, sometimes with fixes. Re-installing the bootloader to use the fresher DTB is not really a nice thing to have to do.

This change makes it so the call to kexec uses the --dtb flag.

But wait, there's more!

The kernel assumes some entries will be added to the FDT (in-memory device tree), like the /memory node. kexec does nothing to help you forward required entries.

This is where fdt-forward comes into play. It is used to get the nodes and properties from the running system.

For the pinephone, you can observe it forwards a property for the Wi-Fi adapter mac address. The bootloader is expected to add a few properties like this depending on the device.

Finally, since we can, let's add some nodes about the current stage-0 boot. This is not strictly needed, but it the basic boolean node can be used as a method to confirm kexec was used. We can also add other properties if it ends up being useful.

fdt-forward?

Are you concerned about what seems like a weird script? I understand. In the end it is much easier to deal with than having to work with libfdt in C or with other language bindings.

I am open to contributions that allows doing the same kind of manipulations. The basic requirements are:

• graft a full node from a DT to another DT (source and binary)
• graft a property with a qualified path from a DT to another DT (source and binary)

The header and to_dtb features are only for convenience.

For the time being, this is not perfect, but totally does what is needed.

[samueldr]

to_json?

Because it will produce and escape strings well enough for use inside DTS files. The required escapes are basically compatible.

[samueldr]

Why shell script for map-dtbs rather than Ruby? Because this is used in building a generation in the target NixOS system. This target system should not require Ruby/mruby in its build closure.

---

Why shell script for fdt-forward? It required chaining calls to different command-line utilities (fdtgrep and dtc). It would have been possible to write a script for that in mruby, but calling an mruby script in stage-1 has bad ergonomics at the time. Alternatively it could be a class that is used directly in the init, but it'd be better if it was FFI bindings to libfdt rather than chaining misc executables.