New booter

New booter

[Benjamin Herrenschmidt]

I've uploaded preliminary work for a new booter, it's available at:

http://calvaweb.calvacom.fr/bh40/test.html and is called "miBoot".

It's a fake MacOS System file that should allow booting on real-ROMs Macs
(pre-new world) without a complete MacOS installed. For the moment, I
mostly tested it with a floppy containing:

 - The fake "System" file,
 - A fake (empty) "Finder" file (with the correct type and creator)
 - A compressed kernel. Currently, the kernel MUST be the normal
"vmlinux" file compressed with a "gzip -vf9 vmlinux" and named
vmlinux.gz. Of course, this may change in the future.

Also, the disk must be "blessed". It must have the correct boot blocks to
be recognized as a bootable disk. A DiskCopy disk image is included in
the archive which should have all the appropriate stuffs. The bootblocks
can be put manualy (block 0 and 1 of the HFS file system) from the "boot"
resource ID 1 in the system.

The current version contains all BootX code (some parts slightly
rewritten, some bugs fixed). It works up to the point where the kernel
tries to boot. The prom.c messages are correctly displayed, the address
(0) seems to be correct, the MSR value too, I made a quick check of the
device tree and it looks ok too, but the kernel hangs. (I tried adding
xmon to the command line, but it won't go that far).

You can get a lot of messages from the booter by pressing the option
(alt) key when it's loaded (just keep it pressed until the happy map is
replaced by... you'll see).

I won't have time to do much more work on this until next week-end, so
feel free to hack, find out why the kernel doesn't boot, etc....

Also, I temporarily removed the NuBus code. I'll put it back in when I
have something more "polished". Most of the code of the boot 2 and 3
resources should work on 68k. Some _StripAddress may be needed on old
ROMs, and a couple of traps may need to be checked for existence before
using them. Also, on those old machines, we may have to hack a bit more
with the MacOS low memory stuffs and heap/stack sizes.

Once finished, this booter should allow to make bootable linux CDs for
all supported macs. The NewWorld mac will need the addition of a
boot-info file and the secondary loader.
It should also allow bootable floppies. For hard disks, it should work
(booting from a small HFS partition like MacOS X) but we sill need a
working disk driver on the hard disk. I have some work in progress for
one, I'll go back at fixing it when miBoot is ok.

Have fun !

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Benjamin Herrenschmidt]

I forgot to mention that the kernel args can be changed by editing the
CMDL resource in the System file with resedit. Don't forget the trailing
0, it's a C string !


-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Daniel Jacobowitz]

On Mon, Sep 13, 1999 at 07:51:46PM +0000, Andreas Bogk wrote:
> 
> Benjamin Herrenschmidt <bh40@calva.net> writes:
> 
> > I forgot to mention that the kernel args can be changed by editing the
> > CMDL resource in the System file with resedit. Don't forget the trailing
> > 0, it's a C string !
> 
> What's the point of a boot application that works without MacOS when
> yu need MacOS to modify the kernel args?


You don't.  You can hack them with a hex editor if you prefer.  Are
there decent tools for dealing with hfs resource forks from linux? Not
that I know of but there is nothing stopping someone from writing one.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Andreas Bogk]

Benjamin Herrenschmidt <bh40@calva.net> writes:

> I forgot to mention that the kernel args can be changed by editing the
> CMDL resource in the System file with resedit. Don't forget the trailing
> 0, it's a C string !

What's the point of a boot application that works without MacOS when
yu need MacOS to modify the kernel args?

Andreas

-- 
"Niemand hat die Absicht, eine Firewall einzurichten"
  -- Peter Berlich <peter@berlich.de>, dasr

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Kevin Puetz]

True, but it would be _much_ more convenient if you could just read them 
from a text file. Eventually, of course. Preferably with a syntax as close
as makes sense to quik.conf/lilo.conf

What a week, quik got fixed, AND a new booter for OF-deficient machines to
free them from needing MacOS just to bootstrap Linux!


----------

> On Mon, Sep 13, 1999 at 07:51:46PM +0000, Andreas Bogk wrote:
>>
>> Benjamin Herrenschmidt <bh40@calva.net> writes:
>>
>> > I forgot to mention that the kernel args can be changed by editing the
>> > CMDL resource in the System file with resedit. Don't forget the trailing
>> > 0, it's a C string !
>>
>> What's the point of a boot application that works without MacOS when
>> yu need MacOS to modify the kernel args?
>
>
> You don't.  You can hack them with a hex editor if you prefer.  Are
> there decent tools for dealing with hfs resource forks from linux? Not
> that I know of but there is nothing stopping someone from writing one.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 13/9/99 Kevin Puetz wrote:

>What a week, quik got fixed, AND a new booter for OF-deficient machines to
>free them from needing MacOS just to bootstrap Linux!

quik is not fixed totally, the first stage loader still does not work 
on newworld macs, unless anyone has some suggestions...



Ethan Benson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OpenPGP encrypted mail accepted.
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/
Key FingerPrint: 371A 7416 5D39 CF2D 9366  8AF6 0139 54F5 3EBD 0FE6
RSA Key FingerPrint: DE8B 74D0 79F1 6176  9AF5 120F 47AD 9B0A
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

resource forks (Re: New booter)

[Ryan Nielsen]

Daniel Jacobowitz wrote:
> You don't.  You can hack them with a hex editor if you prefer.  Are
> there decent tools for dealing with hfs resource forks from linux? Not
> that I know of but there is nothing stopping someone from writing one.

A start would be http://www.con.weslayan.edu/~jsproul/linux/macfontutils.html
http://krazynet.com/hx/cicn.tar.gz is an Apple Color Icon viewer using code from macfontutils.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Benjamin Herrenschmidt]

On Mon, Sep 13, 1999, Andreas Bogk <andreas@andreas.org> wrote:

>> I forgot to mention that the kernel args can be changed by editing the
>> CMDL resource in the System file with resedit. Don't forget the trailing
>> 0, it's a C string !
>
>What's the point of a boot application that works without MacOS when
>yu need MacOS to modify the kernel args?

Hey, wait ! This is just a first prototype ;-)

Hopefully, when finished, all those infos will be in a separate text
file. I also need to make some kind of installer that lays out the small
HFS partition, fills the boot blocks and mark the root directory
"blessed" (in MacOS terminology, that means it contains a valid System file).

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Benjamin Herrenschmidt]

On Mon, Sep 13, 1999, Ethan Benson <erbenson@alaska.net> wrote:

>>What a week, quik got fixed, AND a new booter for OF-deficient machines to
>>free them from needing MacOS just to bootstrap Linux!
>
>quik is not fixed totally, the first stage loader still does not work 
>on newworld macs, unless anyone has some suggestions...

I agree this is not perfect, but as I wrote you privately, we can still
use a small HFS partition with the second stage bootstrap beeing directly
loaded by OF. This works now, I tested it last week. Not perfect, but
better than BootX for those machine since the kernel will now be able to
use RTAS ;-)

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 14/9/99 Benjamin Herrenschmidt wrote:

> >quik is not fixed totally, the first stage loader still does not work
> >on newworld macs, unless anyone has some suggestions...
>
>I agree this is not perfect, but as I wrote you privately, we can still
>use a small HFS partition with the second stage bootstrap beeing directly
>loaded by OF. This works now, I tested it last week. Not perfect, but
>better than BootX for those machine since the kernel will now be able to
>use RTAS ;-)

this would be Ok as a last resort but I do not want to give up on the 
first stage loader just yet!

if only apple's OF were opensource... sigh

BTW i tried loading the second stage loader and it runs but all it 
does is complain that it cannot open disk 0



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

BTW I did send that message to Christian explaining what you are 
trying to do, I have not heard back from him though, I gave him your 
email address and said if he was willing to give some advice to email 
you directly...

I know he travels alot now and does not get to email very quickly...



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Benjamin Herrenschmidt]

On Tue, Sep 14, 1999, Ethan Benson <erbenson@alaska.net> wrote:

>yes it does this on all machines, and frankly I think its a 
>disgusting kludge, that would be OK as a absolute LAST RESORT *after* 
>all attempts to get a proper booter working have failed.
>
>linux in my view is about doing things better, and doing them *right* 
>Linus himself is fairly picky about doing things right instead of 
>doing a kludge that `works'
>
>Apple's attitude seems to be `why do it right when a kludge will do?' 
>I do not want to see linux choose the same philosophy.

>From Apple perspective, it's not a kludge since the final MacOS X will
boot from HFS+ partitions, so it seems logical to have the bootinfo on an
HFS volume.

>sorry to be blunt but just because apple has chosen to kludge their 
>bootloader does NOT mean that is what we should do.
>


-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 15/9/99 Benjamin Herrenschmidt wrote:

> >From Apple perspective, it's not a kludge since the final MacOS X will
>boot from HFS+ partitions, so it seems logical to have the bootinfo on an
>HFS volume.

well regardless its still a kludge from the linux perspective we 
don't use HFS..

and besides that its my opinion that relying on a specific filesystem 
to boot your OS is extremely shortsighted, if later on they want to 
change there filesystem to something better they can't since there 
bootfile would not be readable on this new fs, they are then chained 
to HFS+ forever and end up using kludgy crap like hidden HFS 
filesystems with the boot files. (and besides this not everyone who 
wants to use OSX wants to use HFS)

IMNSHO the only way to boot an OS is to have your firmware load 
whatever is on the disk bootblock which contains the OS loader.  no 
need to bloat the firmware with filesystem code that will inevitably 
become obsolete and useless, and you are no longer chained to your 
current filesystem for all eternity... I have to say that intel 
hardware is far superior to PPC hardware in this respect, booting 
arbitrary OSes independently on intel hw is a complete non issue...

anyway regardless of what apple is doing linux is a different OS it 
does not use HFS and as such using a small useless HFS partition just 
to boot it is a kludge.



Ethan Benson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OpenPGP encrypted mail accepted.
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/
Key FingerPrint: 371A 7416 5D39 CF2D 9366  8AF6 0139 54F5 3EBD 0FE6
RSA Key FingerPrint: DE8B 74D0 79F1 6176  9AF5 120F 47AD 9B0A
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[David A. Gatwood]

On Tue, 14 Sep 1999, Ethan Benson wrote:

> On 14/9/99 Timothy A. Seufert wrote:
> 
> >In fact, I think that's just what OS X does on New World machines.  I
> >recall that it creates a small partition named "Rhapsody Booter" or some
> >such thing.
> 
> yes it does this on all machines, and frankly I think its a 
> disgusting kludge, that would be OK as a absolute LAST RESORT *after* 
> all attempts to get a proper booter working have failed.

That _is_ a proper booter.  I assume you mean that having a booter should
be a last resort after you can't get direct OF loading to work....


> linux in my view is about doing things better, and doing them *right* 
> Linus himself is fairly picky about doing things right instead of 
> doing a kludge that `works'
> 
> Apple's attitude seems to be `why do it right when a kludge will do?' 
> I do not want to see linux choose the same philosophy.

I am, frankly, offended by that statement.  You're talking about what you
see now and using the words "MacOS X".  What you see now doesn't even
remotely resemble MacOS X code-wise.  It's MacOS X Server, not MacOS X. 
Different kernel, totally different source base, probably a different boot
mechanism.

The fact that the current "temporary" code uses what you describe as a
kludge does _not_ in any way mean that Apple's attitude is to use a kludge
instead of doing things right.  MacOS X Server was never intended to be
anything more than a series of hacks to get people by until the real code
comes out.  Period.


> sorry to be blunt but just because apple has chosen to kludge their 
> bootloader does NOT mean that is what we should do.

Doing it "right" means ripping Apple's BrokenFirmware (tm) off the boards
and rewriting it so that everything works.  Short of that, all boot
methods are kludges.  The choice here is whether you want to have to boot
half-way into MacOS (BootX) or have a way that doesn't require any
licensing to distribute in a bootable form (this new thing).

Also, to say that Linux does things "right" is ridiculous.  Linux x86 has
loadlin, which loads from DOS (kinda like BootX app), and syslinux, which
seems similar to what this new booter is doing.  Booting by OF is kind of
like booting with x86's lilo, which isn't always possible on all drives
in all configurations.  That's why they have other things like syslinux
and loadlin.  That's why LinuxPPC has BootX and now... well, whatever this
thing is called... BootY?

In conclusion, Linux has, and always will have kludges as alternative boot
mechanisms for machines that can't boot in the traditional way.  There's
simply no way around it if you want to support a wide range of machines.


David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Peter Bierman]

At 10:38 PM -0800 9/14/99, Ethan Benson wrote:
>On 14/9/99 Timothy A. Seufert wrote:
>
>>In fact, I think that's just what OS X does on New World machines.  I
>>recall that it creates a small partition named "Rhapsody Booter" or some
>>such thing.
>
>yes it does this on all machines, and frankly I think its a
>disgusting kludge, that would be OK as a absolute LAST RESORT *after*
>all attempts to get a proper booter working have failed.
>
>Apple's attitude seems to be `why do it right when a kludge will do?'
>I do not want to see linux choose the same philosophy.
>
>sorry to be blunt but just because apple has chosen to kludge their
>bootloader does NOT mean that is what we should do.


Since I'm the one that came up with the "disgusting kludge", do you have
any ideas to share on how to make it better?

-pmb

--
"UNIX shells in Mac OS X should be unneeded but functional...
                        and have the same installed base as MPW."


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Kevyn Shortell]

Ok, here's the story from the horses mouth.

You need to use HFS to boot, no other method is guaranteed to work.
You can call it a kludge if you want to, but while you up there on
the soapbox, you might want to rethink your statement and consider how
Linux boots on X86.

Linux as a OS, has more kludge factor than anything else on the planet
and it works, people use it, life goes on.

No other boot method besides HFS is going to be tested by Apple in
the Firmware, it's not a requirement for shipping machines at this
time. That may change in the future, but for right now, HFS is it.

Kevyn

At 1:58 AM -0800 9/15/99, Ethan Benson wrote:
>On 15/9/99 Benjamin Herrenschmidt wrote:
>
>> >From Apple perspective, it's not a kludge since the final MacOS X will
>>boot from HFS+ partitions, so it seems logical to have the bootinfo on an
>>HFS volume.
>
>well regardless its still a kludge from the linux perspective we 
>don't use HFS..
>
>and besides that its my opinion that relying on a specific 
>filesystem to boot your OS is extremely shortsighted, if later on 
>they want to change there filesystem to something better they can't 
>since there bootfile would not be readable on this new fs, they are 
>then chained to HFS+ forever and end up using kludgy crap like 
>hidden HFS filesystems with the boot files. (and besides this not 
>everyone who wants to use OSX wants to use HFS)
>
>IMNSHO the only way to boot an OS is to have your firmware load 
>whatever is on the disk bootblock which contains the OS loader.  no 
>need to bloat the firmware with filesystem code that will inevitably 
>become obsolete and useless, and you are no longer chained to your 
>current filesystem for all eternity... I have to say that intel 
>hardware is far superior to PPC hardware in this respect, booting 
>arbitrary OSes independently on intel hw is a complete non issue...
>
>anyway regardless of what apple is doing linux is a different OS it 
>does not use HFS and as such using a small useless HFS partition 
>just to boot it is a kludge.
>
>
>
>Ethan Benson
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>OpenPGP encrypted mail accepted.
>To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/
>Key FingerPrint: 371A 7416 5D39 CF2D 9366  8AF6 0139 54F5 3EBD 0FE6
>RSA Key FingerPrint: DE8B 74D0 79F1 6176  9AF5 120F 47AD 9B0A
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

---------------------------------------------------------------
Kevyn Shortell                    Worldwide Developer Relations
Technology Manager          	  Apple Computer, Inc
kevyn@apple.com                   http://developer.apple.com/
"War doesn't determine who's right. War determines who's left"

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[David A. Gatwood]

On Wed, 15 Sep 1999, Kevyn Shortell wrote:

> Ok, here's the story from the horses mouth.
> 
> You need to use HFS to boot, no other method is guaranteed to work.
> You can call it a kludge if you want to, but while you up there on
> the soapbox, you might want to rethink your statement and consider how
> Linux boots on X86.

Case in point: loadlin and syslinux.  Similar to BootX (app) and this new
booter (BootY?) respectively.


> Linux as a OS, has more kludge factor than anything else on the planet
> and it works, people use it, life goes on.

My thoughts exactly.


David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 15/9/99 Peter Bierman wrote:

>
>
>Since I'm the one that came up with the "disgusting kludge", do you have
>any ideas to share on how to make it better?

yes I have already mentioned it, do it like intel machines do, the 
BIOS (OF) loads code from the bootblock of the disk or root partition 
(marked bootable in the partition table), simple and filesystem 
independent.

requiring a dedicated partition for the BOOTSTRAP is ridiculous. 
and so is chaining oneself to a single filesystem (HFS)

the bootblock method works on most OF machines since there are plenty 
of people using quik to do it, its the newworld machines that are 
either different or broken, however they have a flashable ROM so 
apple can fix this oversight.



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 15/9/99 Kevyn Shortell wrote:

>You need to use HFS to boot, no other method is guaranteed to work.
>You can call it a kludge if you want to, but while you up there on
>the soapbox, you might want to rethink your statement and consider how
>Linux boots on X86.

it boots very cleanly on x86, booting linux instead of windows is 
complete non issue there.

BIOS loads the bootblock from boot disk or if one does not exist it 
looks for a partition marked bootable in the partition table and 
loads the bootblock from that.  the BIOS knows NOTHING about ANY 
filesystem not ext2 not FAT, NTFS, DOSfs, not HFS.  lilo works 
wonderfully, and does not require its very own partition in a 
specific filesystem format to work. *I* think this is a very clean 
way to boot it allows the replacement of the filesystem without 
anything more then a update to lilo at most.  not a whole new machine 
or a kludge like creating dedicated partitions just to bootstrap your 
OS.

>Linux as a OS, has more kludge factor than anything else on the planet
>and it works, people use it, life goes on.

I disagree

>No other boot method besides HFS is going to be tested by Apple in
>the Firmware, it's not a requirement for shipping machines at this
>time. That may change in the future, but for right now, HFS is it.

and as I have said this is very shortsighted, what happens down the 
road when people want a journaled filesystem?  when HFS+ is obsolete 
and you want to replace it? oh darn all your machines won't boot now 
unless you keep an old crufty HFS partition laying around wasting 
space to boot.

the bootstrap process should have NO reliance on a specific filesystem!



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 15/9/99 David A. Gatwood wrote:

>Case in point: loadlin and syslinux.  Similar to BootX (app) and this new
>booter (BootY?) respectively.

these tools along with BootX are fine for some situations, but you 
forget to mention LILO which works more then 90% of the time on intel 
hardware, it does not require windows, it does not require its own 
dedicated partition.  it works very very well.



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 15/9/99 David A. Gatwood wrote:

>That _is_ a proper booter.  I assume you mean that having a booter should
>be a last resort after you can't get direct OF loading to work....

LILO is a proper booter, and the last resort is IF OF cannot be made 
to work properly.



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[David N. Welton]

Speaking of booting stuff, I have an RS6000 F50 here, which I have got
running Yellowdog Linux.  To boot it, I currently use a floppy with
the 2.3.10 kernel.  Does anyone know how to go about booting these
things from the HD?  Various combinations of "boot scsci/sd@8,0...."
don't seem to have much effect on it, which seems logical, as the
kernel is on an ext2 partition.

Also, what is the best place to get the most recent devel kernels?
I'm interested in getting into some of the low level stuff on these
boxes, and want to start from where everyone else is.  I got 2.3.18 to
compile, but it doesn't do much after I boot it... seems to get out of
prom_init and then die somewhere, and I don't know much about getting
further information out of head.S (prom_init is in C and I can call
prom_print).

Anyway, anything people can tell me about this machine, the kernel,
etc, would be quite useful.

Thanks for your time,
-- 
David N. Welton, Developer, Linuxcare, Inc.
415.354.4878 x241 tel, 415.701.7457 fax
dwelton@linuxcare.com, http://www.linuxcare.com/
Linuxcare. At the center of Linux.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Peter Bierman]

>>Since I'm the one that came up with the "disgusting kludge", do you have
>>any ideas to share on how to make it better?
>
>yes I have already mentioned it, do it like intel machines do, the
>BIOS (OF) loads code from the bootblock of the disk or root partition
>(marked bootable in the partition table), simple and filesystem
>independent.

The bootblock on a Macintosh is specified as a structure in an HFS filesystem.

So I'm not sure what you mean then by the "bootblock of the disk".

There's an Apple partition map, which contains a driver map, and other
helpful info. But there's no executable code stored in the partition map.
And the drivers on the disk are loaded by Classic Mac OS (not X).

But the end result is that OpenFirmware on OldWorld machines is not
flashable, and the OF on those machines will boot the Apple ROM on those
machines when result to factory defaults. (Like zapping PRAM).

So unless you want the user to have a rescue CD around for when they zap
PRAM, you need to have *something* on the disk that the Mac OS ROM thinks
is bootable. That's what Ben H. is working on. You don't actually need a
Mac OS System, you just need bits that are in the right place for the ROM
to think they're a System enough to jump into your code.

And part of that "looking like a Mac OS System" is residing on an HFS or
HFS+ disk. Because (once again) when you zap PRAM, OF boots the ROM,
period. It's too late for OF booting then.


>requiring a dedicated partition for the BOOTSTRAP is ridiculous.
>and so is chaining oneself to a single filesystem (HFS)

NewWorld machines have flashable firmware, and OF can then be updated to
understand different filesystems.

But I still have to support the ability to boot *before* OF gets updated.
So for UFS systems on NewWorld machines, we have an HFS volume that
contains all of the OF patches we need, and the booter to find and launch
the kernel from the UFS volume.

HFS systems on NewWorld machines will just boot directly from the root volume.


>the bootblock method works on most OF machines since there are plenty
>of people using quik to do it, its the newworld machines that are
>either different or broken, however they have a flashable ROM so
>apple can fix this oversight.

I haven't used quik, but I'm guessing it patches OF so that OF can read a
booter somewhere? This would be similar to System Disk for OldWorld
machines, which patches OF, and then points it at a loader partition which
contains an expanded XCOFF binary (the same binary as the booter, just in a
format that OldWorld OF can load and execute.)

-pmb

--
"UNIX shells in Mac OS X should be unneeded but functional...
                        and have the same installed base as MPW."


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Tom Rini]

On Wed, 15 Sep 1999, Ethan Benson wrote:

> On 15/9/99 David A. Gatwood wrote:
> 
> >Case in point: loadlin and syslinux.  Similar to BootX (app) and this new
> >booter (BootY?) respectively.
> 
> these tools along with BootX are fine for some situations, but you 
> forget to mention LILO which works more then 90% of the time on intel 
> hardware, it does not require windows, it does not require its own 
> dedicated partition.  it works very very well.

Then you haven't heard enough LILO horror stories.  LILO just kinda works
most of the time.

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Dan Burcaw]

On Wed, 15 Sep 1999, David N. Welton wrote:

> 
> Speaking of booting stuff, I have an RS6000 F50 here, which I have got
> running Yellowdog Linux.  To boot it, I currently use a floppy with
> the 2.3.10 kernel.  Does anyone know how to go about booting these
> things from the HD?  Various combinations of "boot scsci/sd@8,0...."
> don't seem to have much effect on it, which seems logical, as the
> kernel is on an ext2 partition.

David: Best bet is to reinstall.. make a ~10meg PReP Boot partition (type
41) and then install Quik 2 from ftp.ppc.kernel.org/pub/linuxppc/misc/

We haven't tried this, but I've been told it works for RS/6000 + Yellow
Dog booting.

> 
> Also, what is the best place to get the most recent devel kernels?
> I'm interested in getting into some of the low level stuff on these
> boxes, and want to start from where everyone else is.  I got 2.3.18 to
> compile, but it doesn't do much after I boot it... seems to get out of
> prom_init and then die somewhere, and I don't know much about getting
> further information out of head.S (prom_init is in C and I can call
> prom_print).
> 
> Anyway, anything people can tell me about this machine, the kernel,
> etc, would be quite useful.
> 
> Thanks for your time,
> -- 
> David N. Welton, Developer, Linuxcare, Inc.
> 415.354.4878 x241 tel, 415.701.7457 fax
> dwelton@linuxcare.com, http://www.linuxcare.com/
> Linuxcare. At the center of Linux.
> 
> 

Dan

Terra Soft Solutions, Inc.
   Yellow Dog Linux
   "The Ultimate Companion for a Dedicated Server"
   http://www.yellowdoglinux.com/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Peter Bierman]

At 2:37 PM -0800 9/15/99, Ethan Benson wrote:
>BIOS loads the bootblock from boot disk or if one does not exist it
>looks for a partition marked bootable in the partition table and
>loads the bootblock from that.  the BIOS knows NOTHING about ANY
>filesystem not ext2 not FAT, NTFS, DOSfs, not HFS.  lilo works


You contradict yourself. The bootblock IS PART OF THE DEFINITION OF THE
FILESYSTEM.

The DOS bootblock has been carried along by every x86 operating system
ever, because that's the only thing the BIOS has ever understood.

Even NTFS uses the original fdisk pmap, if only to store a single partition
entry that points to a "modern" pmap.

Everything on x86 is an delicate chain built from how it was done in the
1970's!

-pmb

--
"UNIX shells in Mac OS X should be unneeded but functional...
                        and have the same installed base as MPW."


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Dan Burcaw]

> these tools along with BootX are fine for some situations, but you 
> forget to mention LILO which works more then 90% of the time on intel 
> hardware, it does not require windows, it does not require its own 
> dedicated partition.  it works very very well.

Listen, these are issues we've been working on and this is the logical and
WORKING answer. 

Dan

Terra Soft Solutions, Inc.
   Yellow Dog Linux
   "The Ultimate Companion for a Dedicated Server"
   http://www.yellowdoglinux.com/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Wolfgang Denk]

In message <v04210102b405ce2cdefb@[192.168.0.1]> Ethan Benson
<erbenson@alaska.net> wrote:
> 
[about LILO]:
> it boots very cleanly on x86, booting linux instead of windows is 
> complete non issue there.
> 
> BIOS loads the bootblock from boot disk or if one does not exist it 
> looks for a partition marked bootable in the partition table and 
> loads the bootblock from that.  the BIOS knows NOTHING about ANY 
> filesystem not ext2 not FAT, NTFS, DOSfs, not HFS.  lilo works 
> wonderfully, and does not require its very own partition in a 
> specific filesystem format to work. *I* think this is a very clean 
> way to boot it allows the replacement of the filesystem without 
> anything more then a update to lilo at most.  not a whole new machine 

Furthermore, LILO provides with a lot of interesting  options  rarely
used  but  very  powerful  (and  *very* useful for embedded systems):
password protection,  selection  of  alternate  boot  arguments  with
automatic fallback if booting fails etc.

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Old programmers never die, they just branch to a new address.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[erik cameron]

On Wed, Sep 15, 1999 at 02:37:35PM -0800, Ethan Benson wrote:
> anything more then a update to lilo at most.  not a whole new machine 
> or a kludge like creating dedicated partitions just to bootstrap your 
> OS.

i think people were referring to the syslinux/loadlin type setup, rather 
than using lilo straight out off of a bootable partition.

> >Linux as a OS, has more kludge factor than anything else on the planet
> >and it works, people use it, life goes on.
> 
> I disagree

maybe not some versions, currently.  and maybe at some point it won't be
kludgy at all.  but what's more kludgy, BootX or a small HFS partition that
nobody knows is there?  parts of linux *are* still kludgy; this is true.  I
disagree with the assertation that it is "more kludgy than anything else 
on the planet," but i'd prefer it to be ugly and work than beautiful and 
useless.

> unless you keep an old crufty HFS partition laying around wasting 
> space to boot.

a machine running ODS does the same thing to store metadevice info; if you're 
booting off of a metadevice, (and god only knows why you would be, but it happens
a lot) you're doing the same thing.  i've seen a lot of machines that could
hardly called kludgy using this setup exactly.  the point is simply that if it
works, it works, and it makes the machine run better in the long run, it's better
than nothing at all, and certainly better as a "for-now" fix.  i really don't 
think that there is a huge performance/storage space issue at stake; i mean, we're
not talking about booting a commodore 64 here.  it really seems that this is 
an ugly vs. not ugly debate, and purely academic, as there are no other choices.

> the bootstrap process should have NO reliance on a specific filesystem!

and the more vehemently you criticize, the more people are expecting to see
you post a workaround that meets your aesthetic standards.

I agree with you in principle, but I thought the point was to come up with 
a functional booter rather than simply flame apple...  if we were just here
to flame operating system manufacturers, this would be a radically different
list.  :)

-- 
erik cameron  unix systems administrator
jfi/mrsec @ the university of chicago
e-cameron@uchicago.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 15/9/99 Peter Bierman wrote:

>The bootblock on a Macintosh is specified as a structure in an HFS filesystem.

therein lies the problem....

>So I'm not sure what you mean then by the "bootblock of the disk".

on intel machines disks are typically use the very first 512 bytes on 
a disk as a bootblock and partition table, the bootblock portion of 
this is something like 446 bytes long, the BIOS when booting the 
machine has a boot device specified all it does it load that 446 
bytes into memory and execute it that code could be the NT loader the 
old DOS/win95 loader or it could be LILO, that code then can do 
whatever it need to do.  in lilos case it loads its second stage 
loader from the root filesystem and that takes care of loading the 
kernel, if you replace ext2fs with xfs all that needs updating is 
possibly the second stage LILO.  no specific partition or filesystem 
is needed and the BIOS does not care what filesystem you use.

>There's an Apple partition map, which contains a driver map, and other
>helpful info. But there's no executable code stored in the partition map.
>And the drivers on the disk are loaded by Classic Mac OS (not X).

in this case all that is needed is the bootblock on the root 
filesystem which ext2 and hfs both leave room for, a 1024 byte 
nothing at the very beginning of the partition, OF should simply have 
the boot device specified and it should look in the partition table 
for the bootable partition and load the first 1024 bytes of that 
partition into memory and execute it that code can then do whatever 
it needs to do.  this is exactly how quik works or rather worked on 
non newworld macs.  it did not require its own parition and did not 
require HFS.

>But the end result is that OpenFirmware on OldWorld machines is not
>flashable, and the OF on those machines will boot the Apple ROM on those
>machines when result to factory defaults. (Like zapping PRAM).

I agree that is a great deficency of OF.  it should have a interface 
like the PC bios does that does not require a forth programmer to 
configure.

>So unless you want the user to have a rescue CD around for when they zap
>PRAM, you need to have *something* on the disk that the Mac OS ROM thinks
>is bootable. That's what Ben H. is working on. You don't actually need a
>Mac OS System, you just need bits that are in the right place for the ROM
>to think they're a System enough to jump into your code.

this is where I take issue with the design of the macintosh boot 
process, it should not be looking for a file on a filesystem.  the 
nvram should only have teh boot device specified, not a specific OS 
dependant file, macos should have installed a bootblock on the disk 
that OF loaded that took care of finding and loading the MacOS rom 
image, this way you could replace macos with linux or OSX on the same 
disk and never touch OF.

>And part of that "looking like a Mac OS System" is residing on an HFS or
>HFS+ disk. Because (once again) when you zap PRAM, OF boots the ROM,
>period. It's too late for OF booting then.

see above

>
> >requiring a dedicated partition for the BOOTSTRAP is ridiculous.
> >and so is chaining oneself to a single filesystem (HFS)
>
>NewWorld machines have flashable firmware, and OF can then be updated to
>understand different filesystems.

filesystem code does not belong in the firmware.  its not needed 
either if the boot process is done like it is on intel machines, 
which works pretty darn well if you ask me.

>But I still have to support the ability to boot *before* OF gets updated.
>So for UFS systems on NewWorld machines, we have an HFS volume that
>contains all of the OF patches we need, and the booter to find and launch
>the kernel from the UFS volume.

fine maybe you need this on older machines, but the newer machines 
should fix this deficiency, and sport a filesystem INDEPENDANT boot 
process, this way linux and BSD folks don't have to go though such a 
large pain to get their OSes to boot.

>HFS systems on NewWorld machines will just boot directly from the root volume.

if the root volume is HFS, I don't want to use HFS, I like UFS just 
fine, and what if I add xfs or someother filesystem support to darwin 
how do it boot it now? I have to go back to this messy bootstrap 
partition junk.

can you see why relying on HFS or any specific filesystem is inconvenient???
>
>I haven't used quik, but I'm guessing it patches OF so that OF can read a
>booter somewhere? This would be similar to System Disk for OldWorld
>machines, which patches OF, and then points it at a loader partition which
>contains an expanded XCOFF binary (the same binary as the booter, just in a
>format that OldWorld OF can load and execute.)

it does not patch OF at all, here is what quik does:

installs a first stage loader that OF can execute in the first 1024 
bytes of the root filesystem, this code knows how to read the ext2fs 
to find the second stage load that knows how to load the kernel, all 
that needs to be done to OF is this:

setenv boot-device hd:
or if OF cannot seem to figure out what partition is bootable
setenv boot-device hd:7

the problem is something is goofy with the newworld OF where it 
either wont load the bootblock anymore or its just more picky about 
what kinds of scripts it will execute and does not like the quik 
first stage loader at the moment.  quik did work fine on many of the 
pre newworld macs, I think the beige g3s were among them.  (all OSX 
supports anyway)

if you cannot get around the partition hack on older machnes fine use 
it there, but for the newworld flashable macs and all future please 
make a filesystem agnostic boot process.  that is really all I am 
asking of apple.



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Tom Rini]

On Wed, 15 Sep 1999, Ethan Benson wrote:

> On 15/9/99 Peter Bierman wrote:
> 
> >The bootblock on a Macintosh is specified as a structure in an HFS filesystem.
> 
> therein lies the problem....

That's not a problem, that's helpful.  As Kevyn pointed out (maybe just on
IRC) is if you nuke the NVRAM on a SPARC, yer dead.  If you do that on a
Mac, you're fine.  Lots of other archs have the same problem.  re-write
your bootblock, you're dead on x86.  Macs have the "Can't shoot my foot
off" feature.   This isn't bad.

> >So I'm not sure what you mean then by the "bootblock of the disk".
> 
> on intel machines disks are typically use the very first 512 bytes on 
> a disk as a bootblock and partition table, the bootblock portion of 
> this is something like 446 bytes long, the BIOS when booting the 
> machine has a boot device specified all it does it load that 446 
> bytes into memory and execute it that code could be the NT loader the 
> old DOS/win95 loader or it could be LILO, that code then can do 
> whatever it need to do.  in lilos case it loads its second stage 
> loader from the root filesystem and that takes care of loading the 
> kernel, if you replace ext2fs with xfs all that needs updating is 
> possibly the second stage LILO.  no specific partition or filesystem 
> is needed and the BIOS does not care what filesystem you use.

But a good loader knows how to deal w/ FSes.  The FreeBSD loader is
wonderful, and can boot any kernel on the disk, unlike lilo.

> > >requiring a dedicated partition for the BOOTSTRAP is ridiculous.
> > >and so is chaining oneself to a single filesystem (HFS)
> >
> >NewWorld machines have flashable firmware, and OF can then be updated to
> >understand different filesystems.
> 
> filesystem code does not belong in the firmware.  its not needed 
> either if the boot process is done like it is on intel machines, 
> which works pretty darn well if you ask me.

See above.

> >But I still have to support the ability to boot *before* OF gets updated.
> >So for UFS systems on NewWorld machines, we have an HFS volume that
> >contains all of the OF patches we need, and the booter to find and launch
> >the kernel from the UFS volume.
> 
> fine maybe you need this on older machines, but the newer machines 
> should fix this deficiency, and sport a filesystem INDEPENDANT boot 
> process, this way linux and BSD folks don't have to go though such a 
> large pain to get their OSes to boot.

Why do you need a filesystem independant boot process?  That limits us to
something tiny, rather useless and ugly.

> >HFS systems on NewWorld machines will just boot directly from the root volume.
> 
> if the root volume is HFS, I don't want to use HFS, I like UFS just 
> fine, and what if I add xfs or someother filesystem support to darwin 
> how do it boot it now? I have to go back to this messy bootstrap 
> partition junk.

Thats the price to pay for something nice and elegant.

> can you see why relying on HFS or any specific filesystem is inconvenient???

Not really.

> if you cannot get around the partition hack on older machnes fine use 
> it there, but for the newworld flashable macs and all future please 
> make a filesystem agnostic boot process.  that is really all I am 
> asking of apple.

Why?  Why would apple spend all sorts of time and money on something that
gains them nothing.

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[David A. Gatwood]

On Wed, 15 Sep 1999, Tom Rini wrote:

> > >So I'm not sure what you mean then by the "bootblock of the disk".
> > 
> > on intel machines disks are typically use the very first 512 bytes on 
> > a disk as a bootblock and partition table, the bootblock portion of 
> > this is something like 446 bytes long, the BIOS when booting the 
> > machine has a boot device specified all it does it load that 446 
> > bytes into memory and execute it that code could be the NT loader the 
> > old DOS/win95 loader or it could be LILO, that code then can do 
> > whatever it need to do.  in lilos case it loads its second stage 
> > loader from the root filesystem and that takes care of loading the 
> > kernel, if you replace ext2fs with xfs all that needs updating is 
> > possibly the second stage LILO.  no specific partition or filesystem 
> > is needed and the BIOS does not care what filesystem you use.
> 
> But a good loader knows how to deal w/ FSes.  The FreeBSD loader is
> wonderful, and can boot any kernel on the disk, unlike lilo.

Agreed.  In fact, I'd go so far as to say that lilo on PCs is a kludge. 
After all, it's a program that has to fit into a little 512 byte chunk of
tightly coded assembly that has a number of bugs that are, as a result,
hard as heck to fix.  Further, it requires you to have a running linux
system to configure lilo to be able to boot.  What?  You don't have a
running linux system?  Your lilo.conf stuff got hosed?  Go fetch a rescue
disk.

Any booter that doesn't understand filesystems and has to have a list of
blocks is a serious kludge.  For instance, who is to say that you want to
boot off a block device at all?  And what if I wanted to replace a kernel
from within another OS?  Can you say pain in the...

As for the contention that lilo works for 90% of the cases, in only a few
weeks working with x86 machines, I've already run across a case where it
couldn't be installed.  Perhaps a fluke that I'd run across it that
quickly, but a _good_ boot mechanism works 100% of the time.  Depending on
a particular block to be always unused is more than a kludge, it's
downright dangerous.  What if two architectures share a drive?  What if
they happen to pick the same critical boot block?  Baaaad idea.  At least
if it's a filesystem at a particular location, you can read it and say
"hey, that's not a valid fs" or "hey, that partition table is bogus".
With a boot block, there are no second chances.  You just crash.


Later,
David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 15/9/99 Peter Bierman wrote:

>
>You contradict yourself. The bootblock IS PART OF THE DEFINITION OF THE
>FILESYSTEM.

No i don't, there are TWO bootblocks that may be used: one is the MBR 
the Master Boot Record it it at the very start of the disk, then you 
may have a bootblock at the start of each partition if the filesystem 
allows it, the only thing the filesystem needs to do is leave 512 or 
1024 bytes free at the start of the partition, then ANYTHING can be 
put there for the firmware to load.

you ever look at the first 1024 bytes of an HFS partition ? its all 
zeros, same with ext2, until you add a bootblock, macos has one for 
oldworld machines linux has lilo on x86, and on PPC we have quik that 
is broken.

>The DOS bootblock has been carried along by every x86 operating system
>ever, because that's the only thing the BIOS has ever understood.

there is nothing more to the DOS bootblock then free space at the 
beginning of the partition, you can put any code you like there.  the 
only condition is it must be in a language used by the BIOS, just 
like on OpenFirmware machines you can put any code in the bootblock 
so long as its written in Forth.

>Even NTFS uses the original fdisk pmap, if only to store a single partition
>entry that points to a "modern" pmap.

I have not looked at NT enough to know what its filesystems do, but 
as far as bootblocks go it places its NT first stage booter on the 
MBR just like LILO does.

>Everything on x86 is an delicate chain built from how it was done in the
>1970's!

at least you can take a machine from the 1970s and install and boot 
linux and LILO on it without using MS booters or OSes, and without 
creating partitions with fake versions of DOS or windows to boot 
linux.

I call that a working and longterm solution.



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[David D. Kilzer]

Ethan Benson <erbenson@alaska.net> wrote:

>On 15/9/99 Peter Bierman <bierman@apple.com> wrote:
>>Everything on x86 is an delicate chain built from how it was done in the
>>1970's!
>
>at least you can take a machine from the 1970s and install and boot
>linux and LILO on it without using MS booters or OSes, and without
>creating partitions with fake versions of DOS or windows to boot
>linux.
>
>I call that a working and longterm solution.

As HFS is working and longterm solution, though obviously not to your
liking.  That's fine, but you've made your point abundantly clear.  Please
take further discussions off the mailing list or email
<leadership@apple.com> and wait for Steve Jobs to answer you.

Dave


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 15/9/99 erik cameron wrote:

>i think people were referring to the syslinux/loadlin type setup, rather
>than using lilo straight out off of a bootable partition.

BOTH options should be available, for some syslinux/loadlin is more 
convenient, for others LILO is a much nicer solution, especially in 
its ability to load an arbitrary OS it knows nothing about by simply 
loading that OSes bootblock!

> > I disagree
>
>maybe not some versions, currently.  and maybe at some point it won't be
>kludgy at all.  but what's more kludgy, BootX or a small HFS partition that
>nobody knows is there?  parts of linux *are* still kludgy; this is true.  I
>disagree with the assertation that it is "more kludgy than anything else
>on the planet," but i'd prefer it to be ugly and work than beautiful and
>useless.

Linux does have kludges, I do not deny that, but for the most part 
the kludges are unavoidable, and often accompanied by very colorful 
comments in the source leading to censorship issues in australia :-)

the point it Linus and most linux developers PREFER to do things 
right, to implement the cleanest and most efficient way that can be 
done, but often times hardware makers leave stupid bugs in or create 
a shortsighted design that simply does not work well in the long term 
or does not work well outside of the small context the maker had in 
mind, those are places where linux has to kludge its way in, but its 
not prefered and only done if there is no other option.

my objections are twofold:

1) I want ALL avenues of true OF booting by way of the bootblock to 
be explored before giving up and implementing the second best 
alternative, which is partitions and fake macos et al.
2) I am simply very frustrated that apple is being so shortsighted in 
its design of OF and its boot process, they make it so specific to 
MacOS they themselves have challenges getting OSX to boot on their 
own machines! and later on HFS+ will be a obsolete filesystem and 
they will want to replace it again the desisions to make the boot 
process so dependant on HFS is going to haunt them as much as it 
gives migraines to developers of alternative OSes.

> > unless you keep an old crufty HFS partition laying around wasting
> > space to boot.
>
>a machine running ODS does the same thing to store metadevice info; if you're
>booting off of a metadevice, (and god only knows why you would be, 
>but it happens
>a lot) you're doing the same thing.  i've seen a lot of machines that could
>hardly called kludgy using this setup exactly.  the point is simply that if it
>works, it works, and it makes the machine run better in the long 
>run, it's better
>than nothing at all, and certainly better as a "for-now" fix.  i really don't
>think that there is a huge performance/storage space issue at stake; 
>i mean, we're
>not talking about booting a commodore 64 here.  it really seems that this is
>an ugly vs. not ugly debate, and purely academic, as there are no 
>other choices.

I am not yet convinced there are no other options, the options have 
hardly been explored, if there is indeed NO POSSIBLE WAY IN HELL to 
boot these machines without a partition hack then fine, but I am not 
yet satisfied we are to that point, I have been spending alot of time 
investigating this myself, but everytime i try and enlist any 
assistence to explore the issue further everyone seems to just say 
`use bootx' or `just make a kludge partition'  those options are fine 
for some situations and if fixing quik is indeed futile, but I just 
want to make SURE there is not a BETTER way!

> > the bootstrap process should have NO reliance on a specific filesystem!
>
>and the more vehemently you criticize, the more people are expecting to see
>you post a workaround that meets your aesthetic standards.

I have already stated several times how I think the boot process 
should be designed so that it can be truely filesystem agnostic and 
allow a LILO like system with all the niceties like password 
protection, multibooting, multiple images, all in a nice clean 
asthetically pleasing way.

I have also been doing as much research as I get get ahold of on OF 
and Apple's implementation of it, and tinkering with it and quik, 
trying to find a working solution that satisfies my high standards.

>I agree with you in principle, but I thought the point was to come up with
>a functional booter rather than simply flame apple...  if we were just here
>to flame operating system manufacturers, this would be a radically different
>list.  :)
>
>--

I am not here to flame apple, I am very frustrated with them because 
its ultimately their [shortsighted] design that is forcing all these 
messy boot methods, its even causing them headaches in trying to get 
OSX[S] to boot.

I want to come up with more then a simply `functional' booter I want 
to end up with a clean efficient and asthetically pleasing booter.  I 
at least want to TRY, but I cannot do it alone!



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 15/9/99 Tom Rini wrote:

>
>That's not a problem, that's helpful.  As Kevyn pointed out (maybe just on
>IRC) is if you nuke the NVRAM on a SPARC, yer dead.  If you do that on a
>Mac, you're fine.  Lots of other archs have the same problem.  re-write
>your bootblock, you're dead on x86.  Macs have the "Can't shoot my foot
>off" feature.   This isn't bad.

if you overwrite the bootblock on macos your disk will NOT boot, I 
know I have done it many time.

>
>But a good loader knows how to deal w/ FSes.  The FreeBSD loader is
>wonderful, and can boot any kernel on the disk, unlike lilo.

thats fine the problem is relying on using a specific filesystem, 
that is why we are stuck on linux OF does not know about ext2, this 
is why support for arbitrary bootblock loading is needed so if your 
filesystem is unknown to the firmware you are not stuck, you are also 
not stuck using the same fs format forever.

>
>Why do you need a filesystem independant boot process?  That limits us to
>something tiny, rather useless and ugly.

fine have both, we need a fs independant boot process so linux will 
work on this hardware, as it is we are stuck with kludges. (or maybe 
not and we just don't and its just quik thats broken)

the problem with relying on filesystem support in the hardware is its 
difficult to change and for linux developers its effectively 
IMPOSSIBLE to change, you want it thier fine, but do not RELY on that 
EXCLUSIVELY.



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Sean]

*plays the devil's advocate*

"David A. Gatwood" wrote:
> 
> On Wed, 15 Sep 1999, Tom Rini wrote:
> 
> > > >So I'm not sure what you mean then by the "bootblock of the disk".
> > >
> > > on intel machines disks are typically use the very first 512 bytes on
> > > a disk as a bootblock and partition table, the bootblock portion of
> > > this is something like 446 bytes long, the BIOS when booting the
> > > machine has a boot device specified all it does it load that 446
> > > bytes into memory and execute it that code could be the NT loader the
> > > old DOS/win95 loader or it could be LILO, that code then can do
> > > whatever it need to do.  in lilos case it loads its second stage
> > > loader from the root filesystem and that takes care of loading the
> > > kernel, if you replace ext2fs with xfs all that needs updating is
> > > possibly the second stage LILO.  no specific partition or filesystem
> > > is needed and the BIOS does not care what filesystem you use.
> >
> > But a good loader knows how to deal w/ FSes.  The FreeBSD loader is
> > wonderful, and can boot any kernel on the disk, unlike lilo.

How many times do you compile your Linux kernel under say windows or the
macos so it would actually be on a different type of FS where this would
actually be an issue? *ponders*

> Agreed.  In fact, I'd go so far as to say that lilo on PCs is a kludge.
> After all, it's a program that has to fit into a little 512 byte chunk of
> tightly coded assembly that has a number of bugs that are, as a result,
> hard as heck to fix.  Further, it requires you to have a running linux
> system to configure lilo to be able to boot.  What?  You don't have a
> running linux system?  Your lilo.conf stuff got hosed?  Go fetch a rescue
> disk.

Actually, if your MBR bootloader gets hosed on any PC your running for a bootdisk
regardless of OS. Its a problem with the architechure not lilo.
 
> Any booter that doesn't understand filesystems and has to have a list of
> blocks is a serious kludge.  For instance, who is to say that you want to
> boot off a block device at all?  And what if I wanted to replace a kernel
> from within another OS?  Can you say pain in the...

if you dont have a block device, and your not going to boot from it than
why would you worry about whether you have a bootloader installed on a
block device? 

> As for the contention that lilo works for 90% of the cases, in only a few
> weeks working with x86 machines, I've already run across a case where it
> couldn't be installed.  Perhaps a fluke that I'd run across it that
> quickly, but a _good_ boot mechanism works 100% of the time.  

weird i have installed on dozens of systems and lilo has worked
flawlessy, although I have had problems with WD E-Z drive writing over
the boot block stuff a few times(but only windows people are stupid
enough to use it), and I have had to wrestle with some scsi drives, though.

>Depending on
> a particular block to be always unused is more than a kludge, it's
> downright dangerous.  What if two architectures share a drive?  What if
> they happen to pick the same critical boot block?  Baaaad idea.  At least
> if it's a filesystem at a particular location, you can read it and say
> "hey, that's not a valid fs" or "hey, that partition table is bogus".
> With a boot block, there are no second chances.  You just crash.

Lilo, can handle at least 3 OS's. and it also gives errors as best it
can when it crashes.
if the partition table is mucked up.. chances are your MBR is all mucked
up and your not even going to get to the "let's check the partition
table stage"

Don't get me wrong, Im not saying LILO is the be all and end all of
bootloaders, Im not saying its perfect, bugfree or even the best type of
solution for the PPC platform, but at least take fair stabs at it. 

___________

The major advantages I can see to NOT using a boot block type of
bootloader are:

=>you want to netboot and you dont have a net-boot capable nic card than
you could boot into loader type of thing and be able "netboot" it
cheaply =)

=> eliminate architechure differences and be able to have enough room on
the partition to hold all kinds of system specific information.
(depending on the partition dedicated to it)

=> easier to work on since you dont _have_ to do it all in assembly.

The major disadvantages:

=> its still gonna suck for x86 systems since they do look at the boot
block by architechure default and it can be overwritten by other os
installations (such as BeOS, etc) since the hardware _always_ looks at
that spot (but than again x86 has always sucked IMHO) 

=> probably easier to drop a "boot partition" virus on the system
especially from another OS like the MacOS especially if the partition is
hfs it still be affected by things like the hong kong virus and would
still be mounted as a partition when running the MacOS (and if its not
HFS we are still stuck with the OF problems arent we?)

=> still need a separate partition for booting.

=> you would need a "utility" to edit the parameters partition.

=> assembly is a good thing to know =) 

=> the need to repartiton (very slight) i have to repartition and
reinstall anyway *lol*


Did I miss anything?

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Dan Burcaw]

> BOTH options should be available, for some syslinux/loadlin is more 
> convenient, for others LILO is a much nicer solution, especially in 
> its ability to load an arbitrary OS it knows nothing about by simply 
> loading that OSes bootblock!
> 
> > > I disagree
> >
> >maybe not some versions, currently.  and maybe at some point it won't be
> >kludgy at all.  but what's more kludgy, BootX or a small HFS partition that
> >nobody knows is there?  parts of linux *are* still kludgy; this is true.  I
> >disagree with the assertation that it is "more kludgy than anything else
> >on the planet," but i'd prefer it to be ugly and work than beautiful and
> >useless.
> 
> Linux does have kludges, I do not deny that, but for the most part 
> the kludges are unavoidable, and often accompanied by very colorful 
> comments in the source leading to censorship issues in australia :-)
> 
> the point it Linus and most linux developers PREFER to do things 
> right, to implement the cleanest and most efficient way that can be 
> done, but often times hardware makers leave stupid bugs in or create 
> a shortsighted design that simply does not work well in the long term 
> or does not work well outside of the small context the maker had in 
> mind, those are places where linux has to kludge its way in, but its 
> not prefered and only done if there is no other option.
> 
> my objections are twofold:
> 
> 1) I want ALL avenues of true OF booting by way of the bootblock to 
> be explored before giving up and implementing the second best 
> alternative, which is partitions and fake macos et al.

Not going to happen. Do you think we've come to this conclusion for any
other reason then because it's the best solution that we can come up with?
Are responses from Apple engineers not proof enough that this is the best
bet?

> 2) I am simply very frustrated that apple is being so shortsighted in 
> its design of OF and its boot process, they make it so specific to 
> MacOS they themselves have challenges getting OSX to boot on their 
> own machines! and later on HFS+ will be a obsolete filesystem and 
> they will want to replace it again the desisions to make the boot 
> process so dependant on HFS is going to haunt them as much as it 
> gives migraines to developers of alternative OSes.

Well complain to them, not us.. leadership@apple.com. 

> I am not yet convinced there are no other options, the options have 
> hardly been explored, if there is indeed NO POSSIBLE WAY IN HELL to 
> boot these machines without a partition hack then fine, but I am not 
> yet satisfied we are to that point, I have been spending alot of time 
> investigating this myself, but everytime i try and enlist any 
> assistence to explore the issue further everyone seems to just say 
> `use bootx' or `just make a kludge partition'  those options are fine 
> for some situations and if fixing quik is indeed futile, but I just 
> want to make SURE there is not a BETTER way!

We've been exploring the possibilities since the first new world box came
out (iMac). Don't you think Apple would have done it "that way" if it was
possible? I don't know why they designed OF how they did, nor am I
justifying the implimentation, but it's what we have to work with, period.
If there IS a better way, the two Apple engineers on this list which have
been participating in this discussion don't know about it. 

> > > the bootstrap process should have NO reliance on a specific filesystem!
> >
> >and the more vehemently you criticize, the more people are expecting to see
> >you post a workaround that meets your aesthetic standards.
> 
> I have already stated several times how I think the boot process 
> should be designed so that it can be truely filesystem agnostic and 
> allow a LILO like system with all the niceties like password 
> protection, multibooting, multiple images, all in a nice clean 
> asthetically pleasing way.

LILO is asthetically pleasing and clean? 

I'm not arguing with you, just pointing out the fact that some of us have
been there, done that as far as researching this topic. Ben began work on
miBoot because this is the logical and best solution with what we have to
work with. (and there is an obvious need for a working bootloader for old
& new world boxes)

Regards,
Dan

Terra Soft Solutions, Inc.
   Yellow Dog Linux
   "The Ultimate Companion for a Dedicated Server"
   http://www.yellowdoglinux.com/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[David A. Gatwood]

On Thu, 16 Sep 1999, Sean wrote:

> *plays the devil's advocate*
> 
> "David A. Gatwood" wrote:
> > 
> > On Wed, 15 Sep 1999, Tom Rini wrote:
> > 
> > > > >So I'm not sure what you mean then by the "bootblock of the disk".
> > > >
> > > > on intel machines disks are typically use the very first 512 bytes on
> > > > a disk as a bootblock and partition table, the bootblock portion of
> > > > this is something like 446 bytes long, the BIOS when booting the
> > > > machine has a boot device specified all it does it load that 446
> > > > bytes into memory and execute it that code could be the NT loader the
> > > > old DOS/win95 loader or it could be LILO, that code then can do
> > > > whatever it need to do.  in lilos case it loads its second stage
> > > > loader from the root filesystem and that takes care of loading the
> > > > kernel, if you replace ext2fs with xfs all that needs updating is
> > > > possibly the second stage LILO.  no specific partition or filesystem
> > > > is needed and the BIOS does not care what filesystem you use.
> > >
> > > But a good loader knows how to deal w/ FSes.  The FreeBSD loader is
> > > wonderful, and can boot any kernel on the disk, unlike lilo.
> 
> How many times do you compile your Linux kernel under say windows or the
> macos so it would actually be on a different type of FS where this would
> actually be an issue? *ponders*

Build... never.  Download... frequently.


> > Any booter that doesn't understand filesystems and has to have a list of
> > blocks is a serious kludge.  For instance, who is to say that you want to
> > boot off a block device at all?  And what if I wanted to replace a kernel
> > from within another OS?  Can you say pain in the...
> 
> if you dont have a block device, and your not going to boot from it than
> why would you worry about whether you have a bootloader installed on a
> block device? 

True enough.


> weird i have installed on dozens of systems and lilo has worked
> flawlessy, although I have had problems with WD E-Z drive writing over
> the boot block stuff a few times(but only windows people are stupid
> enough to use it), and I have had to wrestle with some scsi drives, though.

Try making it share a large disk with FreeDOS, and you'll find one
problem.  Try using a large ramdisk and you'll find a second.  Those are
the ones that come to mind immediately.


> >Depending on
> > a particular block to be always unused is more than a kludge, it's
> > downright dangerous.  What if two architectures share a drive?  What if
> > they happen to pick the same critical boot block?  Baaaad idea.  At least
> > if it's a filesystem at a particular location, you can read it and say
> > "hey, that's not a valid fs" or "hey, that partition table is bogus".
> > With a boot block, there are no second chances.  You just crash.
> 
> Lilo, can handle at least 3 OS's.

I was referring more to setting up  a system in which a driveis shared
between different machine types, like PPC and x86, for example.  Probably
not a good example, and difficult to do in practice, at least with current
hardware.


> and it also gives errors as best it
> can when it crashes.

LI

;-)


David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Geert Uytterhoeven]

On Thu, 16 Sep 1999, Wolfgang Denk wrote:
> [about LILO]:
> > it boots very cleanly on x86, booting linux instead of windows is 
> > complete non issue there.
> > 
> > BIOS loads the bootblock from boot disk or if one does not exist it 
> > looks for a partition marked bootable in the partition table and 
> > loads the bootblock from that.  the BIOS knows NOTHING about ANY 
> > filesystem not ext2 not FAT, NTFS, DOSfs, not HFS.  lilo works 
> > wonderfully, and does not require its very own partition in a 
> > specific filesystem format to work. *I* think this is a very clean 
> > way to boot it allows the replacement of the filesystem without 
> > anything more then a update to lilo at most.  not a whole new machine 
> 
> Furthermore, LILO provides with a lot of interesting  options  rarely
> used  but  very  powerful  (and  *very* useful for embedded systems):
> password protection,  selection  of  alternate  boot  arguments  with
> automatic fallback if booting fails etc.

If you want a LILO for PPC, please don't start from the PC LILO sources, but
from the m68boot packages. Amiga-Lilo (which I wrote, BTW :-) uses the same
principles as the PC LILO, but it is cleaner, has a simpler to understand
configuration file and a small boot monitor (which can be extended) that can be
protected with a password.

BTW, the main trouble with LILO is that you're hosed if you update your kernel
without rerunning LILO since LILO keeps track of the physical blocks. I
circumvent that problem by having (on my Amiga):

    /boot/vmlinuz -> /boot/vmlinuz-2.2.6
    /boot/test -> /boot/vmlinuz-2.3.16a

After compiling a new kernel, I copy it to /boot (using a new name, of course),
update the symlinks and rerun LILO. If I forget (one of) the last two steps,
nothing bad happens.

IMHO the best thing would be something like MILO on the Alpha. MILO is a
small binary that contains device drivers and filesystems taken from the
standard Linux kernel sources. Hence MILO knows about e.g. your ext2fs
partition and fancy U2W-SCSI adapter. On Alpha the MILO binary is put on a
MSDOS formatted partition. On PPC, you could store it on either a HFS or MSDOS
formatted partition, or use a LILO-alike scheme (raw-blocks). Even BootX could
load MILO under MacOS, if you want that.

Combined, you would have a shared `high-level' booter, which is called by
different `low-level' booters (FS (HFS/MSDOS), raw-blocks, BootX), depending on
your taste and architecture:

 +-----------------+
 | FS (HFS/MSDOS)  +----+
 +-----------------+    |
                        |     +------+
 +-----------------+    +---->|      |
 | raw-blocks LILO +--------->| MILO |----> /etc/milo/config
 +-----------------+    +---->|      |      <kernel anywhere on FS>
                        |     +------+
 +-----------------+    |
 | BootX           +----+
 +-----------------+

Doing it this way, even the raw-blocks LILO stuff can get rid of its main
disadvantage: since the LILO/MILO part is `static', you don't have to rerun
LILO when upgrading your kernel, only after installing/upgrading MILO. So
chances that you screw up are smaller, since MILO knows your FS and can boot
any old kernel on your disks in an emergency.

Comments?

Greetings,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248620 Fax +32-2-7242686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Ethan Benson]

On 16/9/99 Geert Uytterhoeven wrote:

>Doing it this way, even the raw-blocks LILO stuff can get rid of its main
>disadvantage: since the LILO/MILO part is `static', you don't have to rerun
>LILO when upgrading your kernel, only after installing/upgrading MILO. So
>chances that you screw up are smaller, since MILO knows your FS and can boot
>any old kernel on your disks in an emergency.

in essence replace the second stage LILO (/boot/chain.b) with a more 
robust one, that sounds good to me.



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Benjamin Herrenschmidt]

On Thu, Sep 16, 1999, Geert Uytterhoeven <geert@sonycom.com> wrote:

>After compiling a new kernel, I copy it to /boot (using a new name, of
>course),
>update the symlinks and rerun LILO. If I forget (one of) the last two steps,
>nothing bad happens.
>
>IMHO the best thing would be something like MILO on the Alpha. MILO is a
>small binary that contains device drivers and filesystems taken from the
>standard Linux kernel sources. Hence MILO knows about e.g. your ext2fs
>partition and fancy U2W-SCSI adapter. On Alpha the MILO binary is put on a
>MSDOS formatted partition. On PPC, you could store it on either a HFS or
MSDOS
>formatted partition, or use a LILO-alike scheme (raw-blocks). Even BootX
could
>load MILO under MacOS, if you want that.
>
>Combined, you would have a shared `high-level' booter, which is called by
>different `low-level' booters (FS (HFS/MSDOS), raw-blocks, BootX), depending
>on
>your taste and architecture:

I personally tend to think that the small HFS partition is not a so bad
idea. As several person pointed out, the boot block mecanism involves
fitting most of the primary booter in a small space, requires building a
map of the files it must access to, etc...

With a firmware able to load files from a simple file system, eventually
hidden from users, makes things a lot easier, you don't have to rebuild
maps each time you change a file, you can split your booter into several
files if you want to, etc...

For example, under linuxppc, we could mount this bootstrap HFS partition
on /boot, and just copy kernel to this in order to make them available to
the booter.

Of course, all this is specific to PowerMacs, other PPC machine needs a
different boot mecanism anyway.

Back to miBoot, I'll try to get it working first (it seems to work but
the kernel hangs, I don't know why yet and I won't have time to look into
this until this week-end). It doesn't solve all the problems since making
bootable CDs (which is my main goal for now) requires a valid driver on
the CD (only MacOS Toast can do that to my knowledge) and using this
trick to boot from the HD also requires a valid MacOS driver on the disk.

I do have some plans to extend the mecanism further and make a CD driver
to avoid relying on Toast and eventually a hard disk driver too (I do
have a prototype SCSI driver but this requires licenced patches from
Apple to make something really useable).


-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[David A. Gatwood]

On Thu, 16 Sep 1999, Geert Uytterhoeven wrote:

> IMHO the best thing would be something like MILO on the Alpha. MILO is a
> small binary that contains device drivers and filesystems taken from the
> standard Linux kernel sources. Hence MILO knows about e.g. your ext2fs
> partition and fancy U2W-SCSI adapter. On Alpha the MILO binary is put on a
> MSDOS formatted partition. On PPC, you could store it on either a HFS or MSDOS
> formatted partition, or use a LILO-alike scheme (raw-blocks). Even BootX could
> load MILO under MacOS, if you want that.

Kind of like syslinux or loadlin... somewhere in between.


> Combined, you would have a shared `high-level' booter, which is called
> by different `low-level' booters (FS (HFS/MSDOS), raw-blocks, BootX),
> depending on your taste and architecture: 

That's kind of cool.


David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Michel Lanners]

On  16 Sep, this message from Geert Uytterhoeven echoed through cyberspace:
> IMHO the best thing would be something like MILO on the Alpha. MILO is a
> small binary that contains device drivers and filesystems taken from the
> standard Linux kernel sources. Hence MILO knows about e.g. your ext2fs
> partition and fancy U2W-SCSI adapter. On Alpha the MILO binary is put on a
> MSDOS formatted partition. On PPC, you could store it on either a HFS or MSDOS
> formatted partition, or use a LILO-alike scheme (raw-blocks). Even BootX could
> load MILO under MacOS, if you want that.
> 
> Combined, you would have a shared `high-level' booter, which is called by
> different `low-level' booters (FS (HFS/MSDOS), raw-blocks, BootX), depending on
> your taste and architecture:
> 
>  +-----------------+
>  | FS (HFS/MSDOS)  +----+
>  +-----------------+    |
>                         |     +------+
>  +-----------------+    +---->|      |
>  | raw-blocks LILO +--------->| MILO |----> /etc/milo/config
>  +-----------------+    +---->|      |      <kernel anywhere on FS>
>                         |     +------+
>  +-----------------+    |
>  | BootX           +----+
>  +-----------------+
> 
> Doing it this way, even the raw-blocks LILO stuff can get rid of its main
> disadvantage: since the LILO/MILO part is `static', you don't have to rerun
> LILO when upgrading your kernel, only after installing/upgrading MILO. So
> chances that you screw up are smaller, since MILO knows your FS and can boot
> any old kernel on your disks in an emergency.

This is very close to what quik does: a two-stage bootup, where the
first-stage does nothing else than load the second-stage from fixed
blocks on disk. The second-stage can then be of any complexity you want.

Quik might need some work on the second-stage to make it more like what
Geert describes abvove; but the principal is there.

Anyway, as long as you want to be able to boot an OldWorld OF machine,
there is not much choice other than the boot block or a HFS partition
in order to boot.....

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Derek Homeier]

On Thu, 16 Sep 1999 12:47:15 +0200, Benjamin Herrenschmidt <bh40@calva.net> wrote:
> 
> Back to miBoot, I'll try to get it working first (it seems to work but
> the kernel hangs, I don't know why yet and I won't have time to look into
> this until this week-end). It doesn't solve all the problems since making
> bootable CDs (which is my main goal for now) requires a valid driver on
> the CD (only MacOS Toast can do that to my knowledge) and using this
> trick to boot from the HD also requires a valid MacOS driver on the disk.
> 
> I do have some plans to extend the mecanism further and make a CD driver
> to avoid relying on Toast and eventually a hard disk driver too (I do
> have a prototype SCSI driver but this requires licenced patches from
> Apple to make something really useable).
> 
I think the latest mkhybrid <ftp://ftp.ge.ucl.ac.uk/pub/mkhfs/> has provisions 
for installing a boot driver, but it's highly experimental yet. You'd still
need the driver itself, also.

Thanks for your efforts,
							Derek

-- 
Derek Homeier                                           Tel: +49-431-880-4103
Institut fuer Theoretische Physik und Astrophysik       Fax: +49-431-880-4100
der Christian-Albrechts-Universitaet                    Feet:        Room 142
D-24098 Kiel, Germany		      email:  homeier@astrophysik.uni-kiel.de
-----------------------------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New booter

[Benjamin Herrenschmidt]

On Fri, Sep 17, 1999, Derek Homeier <supas100@astrophysik.uni-kiel.de> wrote:

>I think the latest mkhybrid <ftp://ftp.ge.ucl.ac.uk/pub/mkhfs/> has
provisions
>
>for installing a boot driver, but it's highly experimental yet. You'd still
>need the driver itself, also.

The problem with mkhybrid approach is that it will rip only one driver
from the CD. A typical bootable CD now contains both a "patch driver", a
patch partition, and the real driver chained behind those.

I'll look into fixing this once I have finished the hard core booting
stuff. I beleive I'll end up putting a home-made driver in place of the
pieces above. This driver will either look for a keystroke or display a
boot selection dialog and eventually enter the kernel. In the meantime,
if someone wants to know how this "chained driver" mecanism is done, you
can mail me privately.

The only potential problem is that since we lack the Apple patches, the
SCSI and IDE managers in ROM may not be very reliable to load the kernel
(especially the MESH driver which is one of the first thing patched).

Unfortunately, I don't have a CD-RW so I'll have to burn some CDs before
having a working solution. (I'm considering adding a SCSI CD emulation to
MOL).


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/