commit f3fadd5cd765e1b6179a3e7dd389ad8a5cea3a14
parent db4f098c02f3597d6fe696fc9741a9c3824e0505
Author: Daniel Barlow <dan@telent.net>
Date: Tue, 24 Dec 2024 12:20:48 +0000
think
Diffstat:
1 file changed, 36 insertions(+), 0 deletions(-)
diff --git a/THOUGHTS.txt b/THOUGHTS.txt
@@ -6634,3 +6634,39 @@ Read 7491584 bytes from volume recovery to 0000000048000000
Using 'config-1' configuration
Trying 'kernel-1' kernel subimage
Description: ARM64 OpenWrt Linux-6.6.45
+
+Sun Dec 22 17:39:56 GMT 2024
+
+From the output above it looks like the device I have plugged in has
+an openwrt "recovery" image but not a "production" image
+
+It also looks like it will be quite hard work to persuade it to boot
+from usb or anything. It doesn't have any of the extlinux stuff
+but it does have uefi for what that's worth
+
+default boot_production command reads a ubi volume called 'fit' and
+calls bootm on what it finds
+
+we could define boot_production to ubifsmount liminix; ubifs load
+<addr> <filename> (which is a fit) and bootm it. *presumably* we could
+do this from the openwrt recovery image
+
+but could we install the whole system using said recovery image? I
+expect we could do, it only requires getting a tarball onto it and
+unpacking it
+
+however, extlinux is not going to be helpful
+(actually it might be a bit, if we ask it to write the fit as
+well as/instead of the individual files)
+
+maybe we need separate concepts of "the filesystem contains
+stuff we need for boot" and "the stuff we need is the stuff
+that extlinux needs"
+
+each bootloader makes an output called bootfiles, and
+the bootablerootdir output copies from bootfiles
+
+Mon Dec 23 18:28:50 GMT 2024
+
+it might be worth moving ubi option decls into the hardware module, if
+they're hardware-dependent
