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