On Mon, 6 Nov 2000, Bill Studenmund wrote:

> > On Mon, 6 Nov 2000, Henry B. Hotz wrote:
> > 
> > > Now as to that "partition zero" stuff:  as I understand it it's a 
> > > misnomer because there is really a "fake" Apple Partition Map there 
> 
> That's actually not correct. "partition 0" is a kind of notation OF 1 & 2
> used to say, "use whatever looks right". For netbooting, I have to say,
> "boot enet:0". In that case, it uses the bootp info to figure out what to
> tftp.

	I use just "boot enet" and it bootp's just fine with a standard
bootp setup FWIW.

> While there is driver info in block 0 of the Apple partition map (well
> block 0 of the disk), it's certainly not needed on OF 1 & 2 to boot -
> installboot has never set it up right before, yet booted. :-)
> 
> I also think we might need to make two ofwboot.xcf's. I can't netboot the
> one we now have, which is set to work with load-base == 600000 unless I
> have loadbase != 600000. But the MacOS X boot loader (which is the next
> thing to load if I want to boot MacOS) will NOT work with loadbase !=
> 600000. An ofwboot.xcf set for 680000 will netboot fine with load-base ==
> 600000. Yes, this is weird!

	I suppose actually figuring out why we can't netboot at that
address is out of the question? :-) I really don't think that a 56k file
should be causing a problem with OFW. I would think that we are *not* in a
area similar to high-RAM on a *shudder* x86 machine in which there are
volatile things like video ROM area, BIOS, etc. where we would have to
worry about boundaries? Something isn't quite right here. How can we
load an entire 3MB kernel, and MacOS X boots from the same load-base, yet
netbooting freezes the computer there from a 56k file. Is it possible the
ethernet hardware is leaving an interupt enabled, or clearing interuppts
before it finishes loading itself into RAM. Does OS X/public Beta use a
two/three stage booter for OFW 1.x and 2.x? 
	 How about this explination: OFW tftps ofwboot.xcf at the address
ofwboot is compiled to use,then reallocates (or even makes a copy to) 
to the OFW load-base value and executes it. Any chance we are
overwriting an area of our own ofwboot and confusing the heck out
of OFW? Perhaps it treats load-base as an offset of real-base? Anyone
used the fcode-debug or other debuging options on OFW? I really know
absolutely nothing about what I'm talking about, just thinking aloud...


	Chris