commit 395f624338a49ee14b8abbec73d5b64b64245db9
parent e518ab667b21e1013077746fce1f28ffb154c0f6
Author: Daniel Barlow <dan@telent.net>
Date: Sat, 2 Dec 2023 15:31:09 +0000
think
Diffstat:
| M | THOUGHTS.txt | | | 67 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- |
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/THOUGHTS.txt b/THOUGHTS.txt
@@ -3176,6 +3176,9 @@ Turris TODO
- perhaps we need different boot "recipes" - e.g. some device
might want boot.scr and another something different
+
+
+
- create installable tarball and test
- gpio thingy for SFP switching
- iperf
@@ -3188,7 +3191,9 @@ Turris TODO
- how to put device name into the device docs
-- make config.boot.commandLine a single string
+- [WONT] make config.boot.commandLine a single string
+ this sounds sensible but it just makes it harder to put useful comments
+ against command line fragments so that we know why they're there
- usefulness tiers for devices ("stable", "experimental", "wip")
- params for ubi(fs) are a mess
@@ -3255,3 +3260,63 @@ we pick the name of anyway).
So maybe we don't need to rewrite ifwait, we just do it after renaming
the device
+
+Wed Nov 29 21:28:37 GMT 2023
+
+How do we name outputs?
+
+fileystem image
+with-boot filesystem image (e.g. ubifs for belkin)
+tarball
+with-boot tarball (e.g. omnia)
+flashable combined image of kernel + filesystem (e.g. gl-mt*)
+kernel + filesystem image + dtb + tftpboot glue
+kernel + filesystem image + qemu script
+
+we could add initramfs as a separate thing for tftpboot and qemu
+(and FIT images) but it would mean not sharing a kernel with
+the outputs that require embedded initramfs
+
+we can enable with-boot variants of outputs by adding a
+boot.loader config option. if we go that route, can we
+use config options to drive the whole output thingy?
+We could have a config option that just changes "defaultOutput"
+but is that useful?
+
+Maybe the question is: we can choose a different output at build time
+rather than editing configuration - how often is this useful? I think
+tftpboot vs installable is about the only case.
+
+adding a /boot to a filesystem differs from making a combined
+flashable image because it is a config change and not a composition
+of two other already-built outputs.
+
+we could have done tftpboot that way as well, but we chose to unpack
+and repack the fdt so we don't have to build two kernels - and also so
+that we can have both outputs from the same configuration without
+editing any files.
+
+for tftpboot we don't want to make the filesystem embed the kernel
+if we need a separate kernel for booting (guessing we can't usually make
+u-boot loopback mount a downloaded filesystem image). so that points to
+not making it a config option, _or_ to making the inclusion logic
+(hardware wants a kernel in filesystem) && !(output == tftpboot)
+which itself means the output somehow needs to be injected into the
+config
+
+nix-build -I liminix-config=./examples/hello-from-mt300.nix --arg device "import ./devices/my-device" --arg output=tftpboot
+
+let's see if we can not do that?
+
+repacking a ubifs to add /boot is awkward and unpleasant
+
+Thu Nov 30 14:33:08 GMT 2023
+
+We need a new boot-in-rootfs output which calls rootfs with
+(config.filesystem // { /boot ... }) when the device
+type is extlinux
+
+
+can conditionally augment the config.filesystem in the outputs
+that produce filesystems. The condition is "device boots using the
+filesystem, and this is not a tftpboot"
