[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why can't yaboot work with oldworld as first stage?



On Tue, May 15, 2001 at 03:14:29PM -0800, Ethan Benson wrote:
> On Tue, May 15, 2001 at 10:25:42AM -0700, Mike Fedyk wrote:
> > As I understand it, oldworlds will read hfs partitions and try to boot files
> > from it.
> 
> no.  oldworld OpenFirmware does nothing more then activate the
> hardware MacOSROM, this is on a ROM chip and has nothing to do with
> any sort of disk media.  
>

It obviously does more, or quik wouldn't work ;)

> > The only problem I can think of would be the executable format of the boot
> > image, which is probably elf now, and would need to be another format for
> > oldworlds.  
> 
> oldworlds only sorta support xcoff.
>

What executable format is quik in anyway?

> > How hard would it be to just compile yaboot in the oldworld
> > compatible executable format?  
> 
> compile it as an xcoff, but that will not solve anything because
> yaboot is not compatible with oldworld OF.  
>

I understand that, but it would be _made_ to understand oldworlds.

> the other problem is OF HFS support is completly bogus, if it works,
> then its a miracle.  the files have to be perfectly unfragmented and
> the filesystem in a perfect and specific state.  it would not be
> reliable.  
>

Oh, what about fat support?  
Why does it boot reliably with tiny xcoff kernels on floppies?

> > Since it has been proposed to make ybin
> > compatible with oldworlds, why not take it to the last step?
> 
> ybin can be made compatible with oldworlds but not in the way you
> think.
> 
> oldworlds need not and should not use bootstrap partitions, they are a
> kludge, and would be quite unreliable on oldworlds for two primary
> reasons:

Why does newworld need that anyway?  Can't OF > 3.0 work with bootblocks or some
non-partition setup?

> > I know there are technicalities, so let's talk about them.
> 
> the correct way of porting yaboot to oldworlds is to first make it
> compatible with oldworld OF, then to build it as a quik second stage
> loader.  it would then be loaded by quik's current first stage loader
> with which there is really nothing wrong.
> 

Looks good...

> alternativly oldworlds i think have the ability to bootstrap like
> RS/6000's do.  in this case a xcoff yaboot would be dded to a
[snip]
Agreed, that wouldn't be any better, and wouldn't solve OF.

> the thing you are not understanding is that the reason yaboot boots so
> well on newworlds is not because yaboot is the utopia of pristine
> bootloader code (its not, its actually rather a of a mess IMO). its
> because newworlds *have a halfway decent implementation of
> OpenFirmware* 
> 

I do understand that, my quick message didn't convey that understanding.

> replacing quik's second stage with yaboot is still a good idea, since
> they already share a majority of code, it would be one less codebase
> to maintain, and it would fix some quik's annoying flaws such as the
> lack of symlink support.  what it won't necessarily fix is any of the
> unreliablity of OF booting on oldworlds, that solution is twofold:
> 

true...

> first you need to add a *boatload* of kludges and workarounds to
> yaboot or quik or whatever you decide to use, for it to function on
> the total pile of *CRAP* that is oldworld OF.  yaboot currently has NO
> workarounds or kludges for oldworlds to speak of.  so slapping yaboot
> on an oldworld is not going to fix anything, like i have said many
> times, yaboot is NOT the one who deserves credit for reliable OF
> booting on newworlds, its the decent OF implemenatation of newworlds
> that deserves the majority of that credit.  
> 

I think it is now a stated fact in this thread that oldworld OF, yaboot, and
quik are total crap. ;)

> secondly, one of the main problems with quik on oldworlds occurs
> before quik ever even gets loaded into memory and executed: OF disk
> access routines on oldworld is predominantly *BROKEN* this is because
> oldworld OF was never built to boot from disk, since booting macos on
> an oldworld does not involve disk access by OF *at all*.  there is
> NOTHING quik, yaboot, poof, Apple_BootX, can do about that.  the ONLY
> way to fix the broken disk access and executable loading routines is
> via nvramrc patches written in Forth.  apple provides some in the
> SystemDisk control panel, but they are non-free and non-distributable,
> and they dont' even work all the time or support all oldworlds
> (remember apple does not give a rats tail about anything but oldworld
> G3s (and even then i don't think they care much))
> 

Will apple release these patches?  Has darwin made them open anything like
this up to the public?

> here is what i would like to see done:
> 
> 1) make yaboot compatible with quik's first stage bootstrap, and thus
> oldworld OF.
> 
> 2) modify ybin to detect oldworld machines (it already does this and
> larts the user :)) and run the bootblock installer instead of the
> normal newworld installation routines.  
> 
> 3) get nvramrc patches written under a GNU Free licence to fix OF
> enough to boot.  some machines will simply have to accept the fact
> that OF must be displayed to a serial terminal.  however if we replace
> quik's second stage with yaboot the single-key feature i ported from
> silo can make this a non-issue IMO.  simple define backup images and
> an image with append=single. all with single-key.  then set the
> input-device variable to kbd|keyboard.  this way its quite easy to
> boot alternate images `blind'.  perhaps we could teach OF how to send
> a beep to the speaker that yaboot could trigger when its ready for
> input.  (a 20+ second timeout would probably work just fine though).  
> 

Looks good.

> 4) i would like to see a single source tree one can download which
> contains all the source for ybin, yaboot and the oldworld first stage
> stuff.  i really dislike the current mess of having a standalone
> yaboot with no installer, an installer with no yaboot source, and a
> totally seperate, unmaintained oldworld bootloader.  i need to talk to
> benh about this but i have been thinking about maintaining my own
> reference release of a complete bootloader package, including ybin,
> yaboot's source and eventually the quik bootblock installer and first
> stage bootstrap.  

If you do that, I think it will probably become popular.  Especially if you
give cvs access.

> eventually i would structure it so ybin would detect
> when running on an oldworld and if so it would elfextract yaboot to
> /boot/yaboot.b, and run a modified quik bootblock installer that would
> read its first stage from /usr/lib/yaboot/first.b or something. this
> would eliminate all the quik cruft from /boot.  it would also
> eliminate the problem of upgrading the bootloader package perhaps
> breaking your current bootloader by mucking around with the .b files
> in /boot (some of which are found by first stage via a blocklist).
> (people who have used grub will understand my idea).  if we can get
> GNU Free nvramrc patches written i would include and install those as
> well.  assuming of course that either we can detect the right patch
> for the right machine with acceptable sucesss, 

Probable.

or write the patches to
> be portable enough to run on all oldworlds (hahaha </dilusional>).
>

bloat, and how big can nvram get anyway?

> anyway enough blabbering, i look forward to more discussion.  
> 

So, how exactly does this MacOS rom work anyway?

I'm guessing:

look in map for hfs partitions

read partitions until valid system folder is found

execute necisary file

Now...

When/how does it use the driver partitions?

What is apple's license on MacOS 7.5 that they have downloadable?  Would we
be able to dist parts of that under non-free?

Maybe we can use oldworld OF as it was _designed_ and boot with the rom.

This may look like a step backwards, but it may be the only solution in some
cases, or temp solution until nvram patches can be made.

Anyone have docs on what the rom does?  URLs would be nice.

Mike



Reply to: