THOUGHTS.txt

@@ -1233,142 +1233,3 @@ Sat Mar 18 18:02:26 GMT 2023
 What if: we added derivations for "apply openwrt changes" as packages,
 which could then be called from the kernel derivation's extraPatchPhase?
 There could be one for generic and one for each openwrt targetop
-
-Mon Mar 20 18:40:53 GMT 2023
-
-- kexec patch is sent to mailing list, keep an eye for replies
-- watchdog
-- ntp
-- rebuild images for live devices
-- can we build a static busybox with flashcp applet and scp it
- to arhcive etc?
-- [DONE] install mailman and hyperkitty on myhtic, create mailing list
-
-Tue Mar 21 22:59:54 GMT 2023
-
-I haven't found a way to arm the watchdog before userland runs, which
-would be really nice: although there's WATCHDOG_HANDLE_BOOT_ENABLED
-and WATCHDOG_OPEN_TIMEOUT it doesn't seem to be sufficient, Maybe
-those options work only when the hardware watchdog is already
-armed. It might not be completely awful insofar as any failure to
-mount root usually results in panic anyway, so provided we start
-watching early in boot then there's not a big window for anything
-to go wrong
-
-What should the watchdog service do?  Ideally we want something that
-"ratchets" : can be started in early boot and signals health as long
-as the system is starting up, then once the system is in "steady
-state" it stops pinging as soon as any part of that steady state
-becomes unhealthy. This feels like a refinement for a much later
-phase though.
-
-Maybe the health criteria might be
-(sshd and lan services are running) or (time since boot < 120s)
-
-Thu Mar 23 00:11:23 GMT 2023
-
-tftpboot and (kexecboot || flashable) have incompatible DTB-finding
-strategies which is painful if you add both modules and then
-expect tftp booting to still work
-
-Maybe we could patch the kernel to use some better strategy for when
-to use/ignore the bootloader command line: e.g "only if it
-contains the string 'liminix'". Could do this by patching
-arch/mips/kernel/setup.c bootcmdline_init to
-
-if(strstr(arcs_cmdline, "liminix") == NULL) arcs_cmdline[0] = '\0'
-and then defining CONFIG_MIPS_CMDLINE_DTB_EXTEND. The
-bootloader command line then needs to specify only the
-_additional_ parameters that weren't in the DTB
-
-(later: that turned out to be quite straighforward)
-
-Fri Mar 24 23:45:12 GMT 2023
-
-- add ntp support
-- [DONE] expose hydra to internet
-- check MAC address weirdness?
-- call Task 1 "done"
-
-Sun Mar 26 00:19:15 GMT 2023
-
-Would be nice to have a flash.sh built in outputs.flashable
-
-Sun Mar 26 15:27:14 BST 2023
-
-Let's think about services and modules.
-
-Module
-+ can change global config
-  * add users, groups etc
-  * change kernel config
-  * change busybox config
-+ well-typed parameters
-- is a "singleton": can't have the same module included twice
-  with different config. e.g. can't have two hostap modules running on
-  different wlan radios.
-- can't express dependencies: a depends on b
-
-suppose:
-
-* modules add service functions to the config? then there's no
-way to define a service while forgetting to import the module
-
-* we use the lib.types stuff for service function arguments
-
-* maybe we stop naming services.foo for every damn thing
-
-* but remember, s6 services do need unique names
-
-
-imports = [ ../modules/dhcp4 ];
-
-services.dhcp4 = config.services.udhcp {
-  interface = lan.device;
-  options = {
-    foo = true;
-    bar = 42;
-  };
-  depends = [ services.some_other_thing ];
-}
-
-modules/dhcp4 udhcp fn needs to define a type for its argument, then
-use something like
-
-  if arg_type.check def.value then res
-            else throw "The option value `${showOption loc}' in `${def.file}' is not a ${arg_type.name}.")
-
-(where def comes from I don't know yet)
-
-Tue Mar 28 10:44:40 BST 2023
-
-we should reserve the name "service" for actual instantiated
-services. This means we need a name for the functions that
-make services. "class", "template", "fn", "maker", "factory"?
-And a namespace name so they're not interleaved with real
-services, which sort of suggests they are packages
-
-if we want to do services = {
- foo = longrun { ... };
- bar = longrun { ... };
-}
-
-without repeating the `name` as an attribute of the longrun,
-then longrun can't return a derivation: it has to return some
-function that accepts `name` as a parameter.
-
-where services.a depends on services.b, at the time its builder is run
-it needs to know what name s6-rc will use for service b
-
-maybe an s6 service definition should be an attrset not a derivation.
-
-maybe this is outside scope for phase 2
-
-Tue Mar 28 13:22:06 BST 2023
-
-Reading nixos/doc/manual/development/building-parts.chapter.md it
-suggests to me that we should rename config.outputs to
-config.system.outputs. The more general question here is whether it's
-good to be augmenting a variable called "config" with all this
-generated stuff that is patently not configuration - perhaps putting
-it under a "system" key will keep it all in one place

doc/user.rst

@@ -58,12 +58,6 @@ command. You need to locate the "firmware" partition, which you can do
 with a combination of :command:`dmesg` output and the contents of
 :file:`/proc/mtd`
 
-**Don't do this on a device that's running on the same flash partition
-as you're about to overwrite, otherwise you're likely to crash it. Use
-kexecboot (see "Updates to running devices" below) first to reboot
-into a RAM-based system.**
-
-
 .. code-block:: console
 
    <5>[    0.469841] Creating 4 MTD partitions on "spi0.0":
@@ -93,7 +87,7 @@ and then connect to the device and run
 
 .. code-block:: console
 
-   flashcp -v firmware.bin /dev/mtd3
+   flashcp firmware.bin /dev/mtd3
 
 
 
@@ -114,7 +108,7 @@ Flashing from the boot monitor
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you are prepared to open the device and have a TTL serial adaptor
-of some kind to connect it to, you can probably flash it using U-Boot.
+or some kind to connect it to, you can probably flash it using U-Boot.
 This is quite hardware-specific: please refer to the Developer Manual.