Subject: Re: Booting problems and/or how to keep from having them
To: None <port-cobalt@NetBSD.org>
From: Christopher Schultz <christopher.d.schultz@comcast.net>
List: port-cobalt
Date: 07/27/2004 11:49:16
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3A66594990222910D6C61FC2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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?
-chris
--------------enig3A66594990222910D6C61FC2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
iD8DBQFBBnl89CaO5/Lv0PARAhb7AKCkf+nZLm861Qcaz65cdjCR4ecOOQCdGe7I
wmF8F58KGeJzZUAsbtdh5DM=
=N3Z0
-----END PGP SIGNATURE-----
--------------enig3A66594990222910D6C61FC2--