Chris G. Demetriou wrote:

> i recommend doing something like the alpha port does, and pass a magic
> number and a pointer to the bootinfo area into the kernel.  i'm not
> sure i like the alpha version mechanism more than the x86
> length/type/data mechanism, but the magic number + pointer idea's a
> decent one.  That way if you decide you have to move it later, etc.,
> the right thing can happen...

I think the x86 version scales better - unknown types just get ignored so
bootblock vs. kernel differences wont be a problem.

> basically:
> 
> 	(1) if no magic number in the right register then you know the
> 	    pointer's not valid,
> 
> 	(2) else check the bootinfo structs for validity, etc.
> 
> This may also give you the ability to share a bit more code with other
> MIPS ports, if they think it's a useful feature...

Sounds good in theory, but...

>From an implementation point of view, MIPS MI code currently expects
mach_init to take 4 arguments - the pmax uses (argc, argv, magiccode,
ptr) where magiccode and ptr are used for passing the PROM callback
vector.  If we were to pinch (code, ptr) for a bootinfo magic number and
pointer then we couldn't boot old kernels with the new bootblocks.  All
the argument registers are used - I guess we could use two callee saved
or temp regisiters, but that somehow seems kludgey and there's no clean
way to get at them with C code.

I guess at a pinch I could stuff the bootinfo magic number and pointer
in two unused entries in the callback vector, but that sounds kludgey
as well.  Is this better than using a fixed memory location?

Another idea is too look at the two ints immediately before the kernel
start address for a magic number and a pointer.  On the pmax, that
memory is listed as "Additional PROM space" - touching that would be
asking for trouble...  The symbols are after edata, so we can't go
there.

Gak, the best option to me at this stage is sounding like the
overloading some callback vector entries.  At least the first two are
unused, and nothing will ever look in there...

Simon.