On Tue, 27 Jul 2004 11:49:16 -0400, Christopher Schultz
<christopher.d.schultz@comcast.net> wrote:
> Andy,
> 
> > It seems like boot sometimes "just fails" and I can't really tell why.
> > I know I built a 2.0 kernel recently that was bigger than the gzipped
> > limit that the firmware can handle and I forgot about it... I think
> > the generic 2.0-release kernel right now won't work on the Qube2
> > because of this. But I've tried to build kernels that nfs boot and
> > they don't get loaded by the firmware properly for whatever reason.
> 
> I'm no particular expert, but I don't think there's a firmware limit on
> kernels, but that depends greatly on the configuration of all the
> loaders that run befor ethe kernel actually boots.
> 
> For example, the loader chain goes something like this on 1.6/1.6.1:
> 
> 1. Hardware/primordial loader (loads about 512 bytes off the disk)
> 2. Minimal software boot loader (loads a couple of K off the disk)
> 3. Kernel loader (loads the entire kernel off the disk)
> 
> The firmware would only impose the limit on the size of loader #2, which
> is by definition 512 bytes (I think).
> 
> Loader #2 is limited in scope by its own physical size, but can load a
> secondard loader (loader #3) of any necessary size.
> 
> Loader #3 has very few constraints except that loader #2 must be able to
> load it into a known good address space (recently changed to a lower
> address, to work with 16MB machines -- thanks, Dennis!) and still have
> room left over to load the kernel. If you have a 2MB loader (which is
> unreasonable, but I'll just use it for illustrative purposes), then you
> simply cannot have it load a 16MB kernel because the kernel would
> overwrite the loader's code in memory.
> 
> When assisting Dennis in fixing the aforementioned 16MB loader problem,
> he discussed using a re-locatable loader that could pull some dirty
> tricks to work under even the most unfortunate conditions -- like not
> having enough memory to load the loader and the kernel at the same
> time), or at least to detect the memory size and re-locate itself as
> high as possible to avoid clobbering the loader with the kernel.
> 
> How big is your 2.0 kernel?

I recompiled the 2.0 kernel with a lot of things disabled (such as
scsi and some scsi adapters, which probably shouldn't be on by
default). That finally worked. But I do believe the 2.0-release
GENERIC options file should be trimmed.

Are you describing a cobalt bootstrap or i386? That doesn't sound like
cobalt... I think the cobalt firmware wants to find a file called
vmlinux.gz on an ext2 filesystem... There's not outwardly obvious
bootloaders that I know about on this hardware. Or is there?

Andy