@Halcyon
yup.
Ironically I did a similar mistake to resurrect a consumer AR23 router made in 2008.
It has only 32MByte of ram and only 8Myte of soldered NAND-flash, which contains
- bootloader (64Kbyte)
- booting settings (32Kbyte)
- linux kernel 2.6.1* (~2MByte)
- splash rootfs, uclibc-diet based (~5MByte)
- wifi calibration settings (2Kbyte)
After 10 years, the flash-partition containing the splash rootfs gonna corrupted because a couple of NAND-blocks died.
(no matter what you write to those blocks, you will always read-back 0xff --> bye bye flash cells)
So I desoldered the SPI-flash chip for a fresh one, but since the firmware was unable to address more than 8Mbyte of space (d'oh), then I made a different setup:
- (first-stage) bootloader (64Kbyte) <------------ closed source, I cannot touch it
- booting settings (32Kbyte)
- (second-stage) usb-boot-loader (800Kbyte) <------------ my project, to bootstrap from USB
- wifi calibration settings (2Kbyte)
(first-stage) bootloader ---> (second-stage) usb-boot-loader ---> kernel boot
the first stage loads the second stage, which comes with a partial USB2-EHCI-bulk implementation able to
- understand partitions on a USB-bulk device (usually a pendrive, but here you could attach a usb-disk)
- load into ram the first partition (there is no filesystem, it's a wild and raw-read-and-load-into-ram)
- clean the cache and reset the EHCI controller
- understand the elf header of the Linux kernel, at least understand which address to jump to
- jump into that address in ram to start the kernel
So now there is a common USB-pendrive attached to the router, and it's from where the rooter bootstraps and then mounts the rootfs.
Ugly design, prone to failure, no doubts about