think
This commit is contained in:
parent
e518ab667b
commit
395f624338
1 changed files with 66 additions and 1 deletions
67
THOUGHTS.txt
67
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"
|
||||
|
|
Loading…
Reference in a new issue