bootloader ideas

bootloader ideas

[David Monro]

Hi,

(I originally only posted this to -workstation)

I've been thinking about bootloaders. Particularly with respect to PReP
machines.

The current method of making the kernel a binary loaded by the firmware
is a bit of a kluge. It means we have to jump through hoops to change
kernel parameters etc. It seems to me there are two or three obvious
approaches, but first I need some information.

1) What if any services does the PReP firmware provide once it loads an
image? I'm guessing that it isn't a lot, just the residual data to tell
us what hardware we have. I could be wrong here though - can anybody
tell me where to find softcopy PReP documentation?

2) What does the ARC bootloader goop for NT provide in the way of
services? I'm guessing rather more. In particular I suspect we have a
way or reading files, by name, from a FAT16-formatted partition, and
possibly passing them arguments, maybe stored in nvram. This is the way
some Alpha systems do it; you set up an ARC boot entry to run a little
executable (ldmilo.exe) which loads a file called 'milo' from the same
directory and executes it. Milo then takes over and loads the kernel.

Do all the PReP machines have ARC available for them? I would guess most
do, but I could be wrong.

IMHO milo itself is overkill; it actually contains an awful lot of the
kernel code (basically the SCSI drivers etc) so that once loaded it can
load the kernel from any device that linux knows about, even if the
machine firmware and ARC don't know about it. The current PReP boot code
covers that eventuality even if it is a bit of a kluge - as long as the
kernel can be loaded by the firmware (even from floppy) it will work.
Assuming that more PReP machines have ARC images available, I'd be
interested in creating a bootloader which, once loaded from ARC, would
be able to load a kernel image from a device ARC could read, using ARC
services. Anybody got any documentation?

Oh, we could also have the bootloader do a lot of fixing up of things
like the PCI spaces and interrupts - I note that NT and Linux on the
IBM 850 have different ideas of where things are and what interrupts
they use. Seems to work though.

Ideally we would get to the point where all the platform-specific fixup
code etc was moved into the bootloaders, and then do away with the
CHRP/PReP/whatever compile option.

Any comments?

Cheers,

        David

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

Re: bootloader ideas

[Gabriel Paubert]

On Mon, 6 Mar 2000, David Monro wrote:

> I've been thinking about bootloaders. Particularly with respect to PReP
> machines.

Me too...

>
> The current method of making the kernel a binary loaded by the firmware
> is a bit of a kluge. It means we have to jump through hoops to change
> kernel parameters etc. It seems to me there are two or three obvious
> approaches, but first I need some information.
>
> 1) What if any services does the PReP firmware provide once it loads an
> image? I'm guessing that it isn't a lot, just the residual data to tell
> us what hardware we have. I could be wrong here though - can anybody
> tell me where to find softcopy PReP documentation?

It's somewhere on IBM sites if it's still there...

>
> 2) What does the ARC bootloader goop for NT provide in the way of
> services? I'm guessing rather more. In particular I suspect we have a
> way or reading files, by name, from a FAT16-formatted partition, and
> possibly passing them arguments, maybe stored in nvram. This is the way
> some Alpha systems do it; you set up an ARC boot entry to run a little
> executable (ldmilo.exe) which loads a file called 'milo' from the same
> directory and executes it. Milo then takes over and loads the kernel.
>
> Do all the PReP machines have ARC available for them? I would guess most
> do, but I could be wrong.

No, I've never seen a single machine with ARC myself...

> IMHO milo itself is overkill; it actually contains an awful lot of the
> kernel code (basically the SCSI drivers etc) so that once loaded it can
> load the kernel from any device that linux knows about, even if the
> machine firmware and ARC don't know about it. The current PReP boot code
> covers that eventuality even if it is a bit of a kluge - as long as the
> kernel can be loaded by the firmware (even from floppy) it will work.
> Assuming that more PReP machines have ARC images available, I'd be
> interested in creating a bootloader which, once loaded from ARC, would
> be able to load a kernel image from a device ARC could read, using ARC
> services. Anybody got any documentation?

The problem is that ARC has some services, PPCBUG used on Motorola boards
has very likely different ones...

> Oh, we could also have the bootloader do a lot of fixing up of things
> like the PCI spaces and interrupts - I note that NT and Linux on the
> IBM 850 have different ideas of where things are and what interrupts
> they use. Seems to work though.

For starting point see my prepboot bootloader which you can find at
ftp://vlab1.iram.es/linux-2.[23]

it is included in the mvme patches.

Basically:
- for now it adds a new directory (for now), arch/ppc/preepboot and a
CONFIG option to enable it.

- it reorganizes PCI I/O and memory space, actually for my machines based
on Raven/Falcon or Hawk Motorola chipsets, it remaps them completely
to something closer to CHRP

- it initializes video boards with an x86 ROM BIOS emulator if neceessary

- it still needs some work to handle the NVRAM, I want too to get rid of
most kludges in the early part of the kernel

- I have code which correctly gets the interrupt routing from residual
data

- it includes its own virtual memory management system, simple, primitive
and not resistant at all to fragmentation, but anyway it's thrown away
almost immediately,

- it is completely relocatable so that it can run whatever the memory
map of the system is ((except for interrupt vectors which are fixed by
HW). Actually it moves itself high so that it can decompress the kernel
in low memory.


	Gabriel.


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

Re: bootloader ideas

[David Monro]

Gabriel Paubert wrote:
>
> On Mon, 6 Mar 2000, David Monro wrote:

> >
[..]
> > us what hardware we have. I could be wrong here though - can anybody
> > tell me where to find softcopy PReP documentation?
>
> It's somewhere on IBM sites if it's still there...

Got it (and the nvram and residual data specs). Looks like a PReP
machine with Open Firmware would possibly have enough smarts to do
something sensible, but I don't think the 850 and the like implement OF,
so that isn't very useful. Do we know what machines do implement OF,
which ones have ARC available, which ones have PPCbug, and are there any
other PReP machines with none-of-the-above?

[..]
> > Do all the PReP machines have ARC available for them? I would guess most
> > do, but I could be wrong.
>
> No, I've never seen a single machine with ARC myself...

Which machines do you deal with - did they not have an NT port? I could
be wrong, but I thought ARC was pretty much always used to boot NT on
non-intel machines...

[..]
>
> The problem is that ARC has some services, PPCBUG used on Motorola boards
> has very likely different ones...

Very true. Ugh.

>
> > Oh, we could also have the bootloader do a lot of fixing up of things
> > like the PCI spaces and interrupts - I note that NT and Linux on the
> > IBM 850 have different ideas of where things are and what interrupts
> > they use. Seems to work though.
>
> For starting point see my prepboot bootloader which you can find at
> ftp://vlab1.iram.es/linux-2.[23]
>
> it is included in the mvme patches.

I've had a look at this before - didn't work for me at the time, but
that was probably for other reasons. I'll have to give it another shot.
Ahh - I guess there probably wasn't an NT port to a VME bus system :-)
Last mvme box I played with was I think the 131 - 68020 with 68851
running sysv/68k r2v3. Long time ago :-)

It is still part of the kernel image though, isn't it? What I would like
is an interactive standalone bootloader which knows quite a bit about
the individual systems, which is then capable of loading the kernel and
booting it - like milo on the alpha.

>
> Basically:
> - for now it adds a new directory (for now), arch/ppc/preepboot and a
> CONFIG option to enable it.
>
> - it reorganizes PCI I/O and memory space, actually for my machines based
> on Raven/Falcon or Hawk Motorola chipsets, it remaps them completely
> to something closer to CHRP

Hmm. Not sure what mine in the 850 is; lspci mentions a motorola MCP105
Eagle as the host bridge.
>
> - it initializes video boards with an x86 ROM BIOS emulator if neceessary

Nice idea. It would still be kind of hard to access SMS (system
management services, basically the tools to select what device you plan
to boot off etc) if the firwmare doesn't support your video card though.
I don't think the 850 supports serial console at the firmware level
unfortunately :-)

>
> - it still needs some work to handle the NVRAM, I want too to get rid of
> most kludges in the early part of the kernel

Good..

>
> - I have code which correctly gets the interrupt routing from residual
> data
>
> - it includes its own virtual memory management system, simple, primitive
> and not resistant at all to fragmentation, but anyway it's thrown away
> almost immediately,
>
> - it is completely relocatable so that it can run whatever the memory
> map of the system is ((except for interrupt vectors which are fixed by
> HW). Actually it moves itself high so that it can decompress the kernel
> in low memory.

Yeah, I noticed that. Keep up the good work!

btw - which tree are your patches on vlab1 against - Linus', vger or
fsmlabs?

Cheers,

	David

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

Re: bootloader ideas

[Gabriel Paubert]

On Mon, 6 Mar 2000, David Monro wrote:

> Got it (and the nvram and residual data specs). Looks like a PReP
> machine with Open Firmware would possibly have enough smarts to do
> something sensible, but I don't think the 850 and the like implement OF,
> so that isn't very useful. Do we know what machines do implement OF,
> which ones have ARC available, which ones have PPCbug, and are there any
> other PReP machines with none-of-the-above?

I had OF on my early MVME2600 but then Motoroola switched back to PPCBUG.
The OF was so buggy and lacking (no interrupt routing, no RTAS, even told
me that the OpenPIC was at bus 0 device 31 when it was device 0) that it
was useless.

> Which machines do you deal with - did they not have an NT port? I could
> be wrong, but I thought ARC was pretty much always used to boot NT on
> non-intel machines...

I have seen VME boards from several manufacturers, and might see more
soon. All have different firmware, actually I liked very much the first
one which  had a decent OF but it failed after a few weeks of operation.

Right now I only have Motorola to test (26xx, 24xx, hopefully soon
51xx but I know people who use my kernels on 23xx and 27xx).

> > The problem is that ARC has some services, PPCBUG used on Motorola boards
> > has very likely different ones...
>
> Very true. Ugh.

Oh, and BTW the PPCBUG services can't be used with the cache or the MMU
enabled. Even sending a character to the console does not work. Don't
believe the documentation, it is so obviously plain wrong in this respect
that it's not even funny.

I checked on 603e boards, it seems the firmware forces the use of the high
interrupt entry points in ROM by setting MSR[IP] which do not provide
TLB reload handlers and prevents replacing MMU handlers.

In short I can't call PPCBUG services under my own memory management :-(,
it might work if I provided all possible translations that the firmware
use through BATS, but there are only 4 of them.

> > For starting point see my prepboot bootloader which you can find at
> > ftp://vlab1.iram.es/linux-2.[23]
> >
> > it is included in the mvme patches.
>
> I've had a look at this before - didn't work for me at the time, but
> that was probably for other reasons. I'll have to give it another shot.
> Ahh - I guess there probably wasn't an NT port to a VME bus system :-)
> Last mvme box I played with was I think the 131 - 68020 with 68851
> running sysv/68k r2v3. Long time ago :-)
>
> It is still part of the kernel image though, isn't it? What I would like
> is an interactive standalone bootloader which knows quite a bit about
> the individual systems, which is then capable of loading the kernel and
> booting it - like milo on the alpha.

Well it is part of the kernel image but it needs not be actually. You can
look at it as an MS-DOS like system. It would be fairly easy to add simple
drivers:it already provides simple memory management, console I/O and
basic PCI configuration services for a single task which may be anything
you want (right now it is decompressing an embedded kernel image +
setting bootinfo + moving initrd around). But it could also load another
image from disk or network, actually I wanted to do it but the PPCBUG
problems make it painful (include a simple fs which can read the kernel
image and pass it the correct parameters).

However I would not like to add interrupt management since polling should
be sufficient in a bootloader. Better clock and timing management could be
added if it simplifies the handling of timeouts however. As long as it's
mostly my code, I'll try to prevent needless bloat, however.


> Hmm. Not sure what mine in the 850 is; lspci mentions a motorola MCP105
> Eagle as the host bridge.

Fine, it's a standard PreP bridge, old but working. It can't be used for
CHRP like mappings though AFAIR (unlike the 106).

> >
> > - it initializes video boards with an x86 ROM BIOS emulator if neceessary
>
> Nice idea. It would still be kind of hard to access SMS (system
> management services, basically the tools to select what device you plan
> to boot off etc) if the firwmare doesn't support your video card though.

Indeed, unless you rewrite the firmware...

> I don't think the 850 supports serial console at the firmware level
> unfortunately :-)

PPCBUG does, actually most of my boxes are headless (don't even have a
keyboard interface or USB, which makes it somewhat awkward to plug in
a standard keyboard).

AIX firmware certainly had some support for serial console. Can't you put
a different firmware in your box (I know I'm lucky with the MVME boards,
they have 2 separate Flash ROMS and a jumper to select the one used at
reset so I can test a new firmware version and easily switch back to the
previous one if it fails).

> > - it is completely relocatable so that it can run whatever the memory
> > map of the system is ((except for interrupt vectors which are fixed by
> > HW). Actually it moves itself high so that it can decompress the kernel
> > in low memory.
>
> Yeah, I noticed that. Keep up the good work!
>
> btw - which tree are your patches on vlab1 against - Linus', vger or
> fsmlabs?

Linus', I might try fsmlabs when BK it becomes official but I was so
severely burnt the day vger was closed to the public (had to modify
something like 600 files to get my systems to boot again), that I'm going
to be very reluctant to try anything else. Besides there are mirrors of
Linus'tree everywhere, but from here a checkout of vger does not always
finish overnight :-(

	Cheers,
	Gabriel.


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

Re: bootloader ideas

[Kazunori Aoshima]

Hi,

Return for :
From: David Monro <davidm@amberdata.demon.co.uk>
on " bootloader ideas "
date: Mon, 06 Mar 2000 06:52:37 +0000 >>>

> Hi,
>
> I've been thinking about bootloaders. Particularly with respect to PReP
> machines.
>
> The current method of making the kernel a binary loaded by the firmware
> is a bit of a kluge. It means we have to jump through hoops to change
> kernel parameters etc. It seems to me there are two or three obvious
> approaches, but first I need some information.
>
> 1) What if any services does the PReP firmware provide once it loads an
> image? I'm guessing that it isn't a lot, just the residual data to tell
> us what hardware we have. I could be wrong here though - can anybody
> tell me where to find softcopy PReP documentation?
>
> 2) What does the ARC bootloader goop for NT provide in the way of
> services? I'm guessing rather more. In particular I suspect we have a
> way or reading files, by name, from a FAT16-formatted partition, and
> possibly passing them arguments, maybe stored in nvram. This is the way
> some Alpha systems do it; you set up an ARC boot entry to run a little
> executable (ldmilo.exe) which loads a file called 'milo' from the same
> directory and executes it. Milo then takes over and loads the kernel.
>
> Do all the PReP machines have ARC available for them? I would guess most
> do, but I could be wrong.

I think so, too.
Some of PRePs cannot install because of ARC firmware.
They cannot rewrite itself from ARC to PRePspec firmware.
And, FireWorks PReP machines maybe needs such loader.

If there are some bootloader like MILO, copy a loader kernel
on DOS based partition, it is very useful for all PRePs.

MILO is ported on MIPS and Alpha based machines, they have some
relationship with ARC.  Maybe they have a same root, and compiled
for each machines.  (Is it true? Please correct me.)

But I am afraid it need to make with original compiler.
(I suppose this needs some cross compile method for ARC-PPC. )


> IMHO milo itself is overkill; it actually contains an awful lot of the
> kernel code (basically the SCSI drivers etc) so that once loaded it can
> load the kernel from any device that linux knows about, even if the
> machine firmware and ARC don't know about it. The current PReP boot code
> covers that eventuality even if it is a bit of a kluge - as long as the
> kernel can be loaded by the firmware (even from floppy) it will work.
> Assuming that more PReP machines have ARC images available, I'd be
> interested in creating a bootloader which, once loaded from ARC, would
> be able to load a kernel image from a device ARC could read, using ARC
> services. Anybody got any documentation?

Linux/MIPS FAQ have some information for ARC, but they say ARC is
not a right firmware, only it boots up NT.
Maybe ARC have no work for device detection.

> Ideally we would get to the point where all the platform-specific fixup
> code etc was moved into the bootloaders, and then do away with the
> CHRP/PReP/whatever compile option.

How cool it is!


Best regards.
----------------------
Kaz Aoshima = Editor of the PReP station
Material deveropment, Faculty of engineering,
Tohoku University, Japan
E-mail:aoshimak@mail.cc.tohoku.ac.jp
#I would appreciate if you could give me suggestions
 for my impolite English expressions.

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

Re: bootloader ideas

[Tim Riker]

I also believe that we need to move most of the platform-specific fixup
code into a boot loader. I am looking into GRUB at this point:

http://www.gnu.org/software/grub/

The stage1 loader would need to have new ppc support, but this would
allow for complete fs support in the stage2 loader.

I will will look more at the other choices out there, but I've been real
happy with grub on x86 and it is fairly clean code. stage2 is in C and
shares much of the kernel FS code.

Thoughts?

Kazunori Aoshima wrote:
>
> Hi,
>
> Return for :
> From: David Monro <davidm@amberdata.demon.co.uk>
> on " bootloader ideas "
> date: Mon, 06 Mar 2000 06:52:37 +0000 >>>
>
> > Hi,
> >
> > I've been thinking about bootloaders. Particularly with respect to PReP
> > machines.
> >
> > The current method of making the kernel a binary loaded by the firmware
> > is a bit of a kluge. It means we have to jump through hoops to change
> > kernel parameters etc. It seems to me there are two or three obvious
> > approaches, but first I need some information.
> >
> > 1) What if any services does the PReP firmware provide once it loads an
> > image? I'm guessing that it isn't a lot, just the residual data to tell
> > us what hardware we have. I could be wrong here though - can anybody
> > tell me where to find softcopy PReP documentation?
> >
> > 2) What does the ARC bootloader goop for NT provide in the way of
> > services? I'm guessing rather more. In particular I suspect we have a
> > way or reading files, by name, from a FAT16-formatted partition, and
> > possibly passing them arguments, maybe stored in nvram. This is the way
> > some Alpha systems do it; you set up an ARC boot entry to run a little
> > executable (ldmilo.exe) which loads a file called 'milo' from the same
> > directory and executes it. Milo then takes over and loads the kernel.
> >
> > Do all the PReP machines have ARC available for them? I would guess most
> > do, but I could be wrong.
>
> I think so, too.
> Some of PRePs cannot install because of ARC firmware.
> They cannot rewrite itself from ARC to PRePspec firmware.
> And, FireWorks PReP machines maybe needs such loader.
>
> If there are some bootloader like MILO, copy a loader kernel
> on DOS based partition, it is very useful for all PRePs.
>
> MILO is ported on MIPS and Alpha based machines, they have some
> relationship with ARC.  Maybe they have a same root, and compiled
> for each machines.  (Is it true? Please correct me.)
>
> But I am afraid it need to make with original compiler.
> (I suppose this needs some cross compile method for ARC-PPC. )
>
> > IMHO milo itself is overkill; it actually contains an awful lot of the
> > kernel code (basically the SCSI drivers etc) so that once loaded it can
> > load the kernel from any device that linux knows about, even if the
> > machine firmware and ARC don't know about it. The current PReP boot code
> > covers that eventuality even if it is a bit of a kluge - as long as the
> > kernel can be loaded by the firmware (even from floppy) it will work.
> > Assuming that more PReP machines have ARC images available, I'd be
> > interested in creating a bootloader which, once loaded from ARC, would
> > be able to load a kernel image from a device ARC could read, using ARC
> > services. Anybody got any documentation?
>
> Linux/MIPS FAQ have some information for ARC, but they say ARC is
> not a right firmware, only it boots up NT.
> Maybe ARC have no work for device detection.
>
> > Ideally we would get to the point where all the platform-specific fixup
> > code etc was moved into the bootloaders, and then do away with the
> > CHRP/PReP/whatever compile option.
>
> How cool it is!
>
> Best regards.
> ----------------------
> Kaz Aoshima = Editor of the PReP station
> Material deveropment, Faculty of engineering,
> Tohoku University, Japan
> E-mail:aoshimak@mail.cc.tohoku.ac.jp
> #I would appreciate if you could give me suggestions
>  for my impolite English expressions.
>

--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

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

Re: bootloader ideas

[Gabriel Paubert]

On Mon, 6 Mar 2000, Tim Riker wrote:

>
> I also believe that we need to move most of the platform-specific fixup
> code into a boot loader. I am looking into GRUB at this point:
>
> http://www.gnu.org/software/grub/
>
> The stage1 loader would need to have new ppc support, but this would
> allow for complete fs support in the stage2 loader.
>
> I will will look more at the other choices out there, but I've been real
> happy with grub on x86 and it is fairly clean code. stage2 is in C and
> shares much of the kernel FS code.

Most of the code is probably fine, with the probably non trivial problem
that stage1 uses the BIOS to load stage2. And even stage2 might still use
the BIOS to load the kernel. That's the major problem since depending on
the PPC machine the firmware services are very different (PPCBUG, ARC,
Open Firmware), when they can be made to work. Otherwise you've to add
additional device drivers.

	Gabriel.


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