From 5a2963543ea058fdb2c7d3bde85e82c6e6069fa5 Mon Sep 17 00:00:00 2001 From: Daniel Barlow Date: Mon, 4 Dec 2023 23:29:36 +0000 Subject: [PATCH] thonk --- THOUGHTS.txt | 61 +++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 56 insertions(+), 5 deletions(-) diff --git a/THOUGHTS.txt b/THOUGHTS.txt index c261f07..12d5382 100644 --- a/THOUGHTS.txt +++ b/THOUGHTS.txt @@ -3312,11 +3312,62 @@ 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 +~~We need a new boot-in-rootfs output which calls rootfs with (config.filesystem // { /boot ... }) when the device -type is extlinux +boot type is extlinux~~ +~~Do we need to put it in systemConfiguration as well? Yes, +otherwise liminix-rebuild won't install it~~ -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" +We may have a problem here actually: if /boot is only set up after +reboot, by adding a link while running the initramfs, how did the +bootloader find the kernel to boot in the first place? So +we need /boot to exist and to point to the new kernel before rebooting +into it, so we need to create it as a real directory along with /nix/store +when making the filesystem, +instead of relying on activate which will be too late. + +maybe we could extract the root directory structure creation +as a separate output from rootfs, then there is a single place +to put "and also add /boot" + +we will need to update pkgs/min-copy-closure/liminix-rebuild.sh +to add /boot + +we could make the contents of /boot a derivation and then +/boot itself is just a symlink to it. we would need to ensure that +the derivation is part of the system closure, though + +Sat Dec 2 15:33:07 GMT 2023 + +- make rootfs the directory structure + +Sun Dec 3 23:31:35 GMT 2023 + +Spent too much of the weekend first fighting run-liminix-vm.sh and +then rewriting it in Fennel, but we are now at the point that we can +boot u-boot in qemu. However, it maps the rootfs into high memory +where phram can find it, instead of putting it into a flash that +_qemu_ can see as flash, so u-boot is not able to boot the kernel or +at least not in a similar-to-hardware fashion. Once we've added that, +we need to write a test for boots-a-kernel-in-the-filesystem + +Mon Dec 4 19:46:58 GMT 2023 + +We wanted a test that we are creating an image that u-boot can boot +using extlinux. Turns out that u-boot only has scripts to do this in +the case that the storage device has a partition table. Which is +representative of the Omnia mmc, but maybe not going to work for +jffs2/ubifs + +(For ubifs it might be OK, there's some concept of partitions + +ubifs_boot=if ubi part ${bootubipart} ${bootubioff} && ubifsmount ubi0:${bootubivol}; then devtype=ubi; devnum=ubi0; bootfstype=ubifs; distro_bootpart=${bootubivol}; run scan_dev_for_boot; ubifsumount; fi + +) + +So what do we need? a disk image with a partition table and an ext4fs +image in the only partition, and that partition to be bootable. Then +run-liminix-vm gets a --disk-image option which causes it to use +U-Boot instead of direct load (can we wrap it with something that sets +up the paths so it can find u-boot and qemu?)