On 3/27/2021 21:00, Rich Freeman wrote: > On Sat, Mar 27, 2021 at 5:43 PM Joshua Kinard <ku...@gentoo.org> wrote: >> >> I kinda wish the Linux kernel had an ability to partially boot, init the >> networking subsystem, then fetch an initramfs image over TFTP like it can do >> with NFS Root. That would solve the problem on my MIPS system(s) (and make >> install netboots better). I've dug around, but this does not seem to be a >> capability currently in the kernel, unless I have over looked something. > > Support exists, in the form of an initramfs. Bear with me for a second. > > An initramfs does not need to be large. It is just software. Sure, > they're often implemented in bash with all sorts of userspace tools in > the image, and that uses lots of space. However, an initramfs could > be nothing but a small compiled binary and nothing else - a few > kilobytes even. > > I'm not aware if anything like this has already been created, but you > could do something reminiscent of coreboot, and it would be > distro-agnostic. Just build a minimal kernel with only support for > whatever you need to read a kernel and initramfs (from disk, network, > whatever). Then build an initramfs that minimally fetches that kernel > - it could just be a tiny binary, or it could use tools like curl/etc. > Then you'd kexec the new kernel/initramfs which would do the full > boot, and this wouldn't have any size limitation. > > An initramfs is just a way to automate the kernel boot process using > userspace code, vs needing to do a lot of fancy stuff in kernel space. > They can get a bit bloated when you make them full-featured/generic, > but if you just want a secondary bootloader you can shrink both the > kernel and the initramfs considerably, and use that to boot another > kernel. > > If I were to look anywhere for something I could use out-of-the-box it > would be with coreboot. That is a linux-based kernel/initramfs > designed to be a bootloader really.
I believe kexec support is fairly new on MIPS, and I am not 100% certain it works with the older SGI hardware. Each SGI machine is not entirely dissimilar from a unique sub-architecture, with their own memory map layouts that are enforced at the PROM level. I believe that kexec is picky about where it stores or jumps into the newer kernel, and on the SGI machines, that's going to be tricky, since there's only one or two FreeMemory() areas available to load things into. And it may not even work at all on the IP27 platform that is ccNUMA-aware and can have memory scattered across multiple physical machine nodes (and I lack the hardware and 240V plugs to even test this). As such, this might be an endeavor that has too much overhead to attempt. As it stands, I currently only have 5.4 LTS kernels working on Octane (IP30) and Origin/Onyx (IP27). There were massive changes from 5.5 through 5.7 that deal with the mainlining of the SGI Octane code (and cleanups in the IP27 PCI core) that I haven't had time to deal with yet, so I am quite a ways behind on things. Hope to take a crack at porting to 5.10 in the next few months (which is why I am sticking to LTS kernels now -- mainline kernels move too fast these days). -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
