Re: boot methods

Re: boot methods

[Michael Sokolov]

Paul Mackerras <paulus@samba.org> wrote:

> There is improvement because you can have a separate wrapper for each
> firmware, if necessary.  At present if we want to change the way
> information is passed into the kernel, we have to synchronously change
> several different firmware/booter implementations, which are
> maintained in separate places by separate people.  The list includes
> (at least) BootX, miboot, yaboot, PPCBoot, and Michael Sokolov's VAX
> console.  This is a logistical nightmare.  Just getting the updates
> into the firmware/booters is bad enough, but then you create problems
> for users who then can't boot old kernels with the new firmware or new
> kernels with the old firmware.

Just for the record, in my case there is no problem with either getting the
changes into the Linux booter or new and old kernels coexisting. My firmware,
which is indeed a VAX console clone for PPC, knows absolutely nothing about how
to boot Linux or any other OS, just like the real VAX console. Just like the
real VAX console, it hands the problem of booting the user's OS of choice to
the OS vendor. To boot Linux I have an entity called ppc-linux-boot, which is
completely free, maintained in public CVS, and not tied to or controlled by SBS
or any other hardware/firmware vendor.

As ppc-linux-boot is free, public, and independent of the SBS firmware, there
can no problem with people changing it any way they want. It is not part of the
system ROM, it is a user-installed utility stored in the user console store, so
any user can easily and legitimately change it whenever s/he likes without
needing any blessing from the hardware manufacturer, and can use experimental
versions hacked by anyone in the world if s/he likes.

When the vmlinux boot interface changes for a platform supported by ppc-linux-
boot, I'll change runlnx (the part of ppc-linux-boot that actually transfers
control to vmlinux) accordingly. I can make the new version support both old
and new kernels by having a boot flag (the user always has to set the correct
boot flags anyway) select the kernel boot interface.

> The reason that nothing has been done is precisely because it is so
> hard at present to change the way that information is passed into the
> kernel, because we still boot the vmlinux directly in some situations.

But currently the vmlinux boot interface is defined per platform: the generic
code passes the initial R3-R7 to platform_init(). It should be possible for a
board port maintainer to change this interface in his/her port without
affecting anyone else.

> If we absolutely *have* to boot a vmlinux directly without a wrapper,
> then probably the best thing is to use bi_recs and pass in a pointer
> to them, since that is reasonably flexible and can be made to be
> forwards and backwards compatible without too much pain.

Yes, and I'm looking forward to usable bi_recs.

> Changing to
> this scheme is going to cause considerable pain in the short term,
> though.

Not at all. Here's how you can make it painless. In arch/ppc/kernel/setup.c
change the division of labor between machine_init and parse_bootinfo. Move the
current logic for locating bi_recs in memory from parse_bootinfo to
machine_init, passing the pointer to bi_recs to parse_bootinfo() as an
argument. Then new board ports can be designed with a bi_recs interface instead
of the current traditional one by doing something like parse_bootinfo(r3) in
platform_init. Existing ports can be converted gradually as their users work
out the transition. I would gladly change the SBS board ports. In fact, one
should first check if the current memory-based bi_recs are being used by anyone
at all. If they aren't, change parse_bootinfo() to take a pointer, remove its
invokation from machine_init altogether, and leave it up to subarch maintainers
to call it from their platform_init's when they are ready to change. Or if the
current memory-based bi_recs are only used on CONFIG_ALL_PPC, do the same but
put the code for locating them and calling parse_bootinfo() in pmac_init,
prep_init, and chrp_init for now. This would have zero impact on CONFIG_ALL_PPC
users while clearing the way for board port maintainers to convert to bi_recs
individually when they are ready.

--
Michael Sokolov				5791 VAN ALLEN WAY
Software Engineer			CARLSBAD CA 92008-7321 USA
SBS Technologies, Inc.			Phone: +1-760-438-6900 x2347
Communications Products			    or  1-888-SBS-COMM x2347
					Fax:   +1-760-438-6985
					E-mail: msokolov@sbs.com
					     or msokolov@ivan.Harhan.ORG

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

Re: boot methods

[Paul Mackerras]

Michael Sokolov writes:

> But currently the vmlinux boot interface is defined per platform: the generic
> code passes the initial R3-R7 to platform_init(). It should be possible for a
> board port maintainer to change this interface in his/her port without
> affecting anyone else.

Yes, that is a very good point.

> In arch/ppc/kernel/setup.c
> change the division of labor between machine_init and parse_bootinfo. Move the
> current logic for locating bi_recs in memory from parse_bootinfo to
> machine_init, passing the pointer to bi_recs to parse_bootinfo() as an
> argument. Then new board ports can be designed with a bi_recs interface instead
> of the current traditional one by doing something like parse_bootinfo(r3) in
> platform_init.

An excellent suggestion.  Thank you.  Is anyone using the bi_recs in
anger yet?

For CONFIG_ALL_PPC, we need to make a wrapper which can be booted
using existing installed versions of BootX/quik/yaboot, which will
accept the parameters as provided by those loaders and make up a set
of bi_recs.  Then we can require that pmac/prep/chrp _always_ use a
wrapper, and then start to move the Open Firmware calls into the
wrapper.

Other platform maintainers can use a wrapper or not as they choose.
For consistency and simplicity it would be nice if there was a
standard register assignment on entry, for example having the physical
address of the bi_recs in r3, but that is not essential.

We should all agree on a comment set of bi_rec tags and the format for
each type of entry.  And I like Ben's suggestion of keeping the bi_recs
around.

Reactions?  Thoughts?  Comments?

Paul.

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

Re: boot methods

[Wolfgang Denk]

In message <15312.5879.511865.946406@cargo.ozlabs.ibm.com> you wrote:
>
> Other platform maintainers can use a wrapper or not as they choose.
> For consistency and simplicity it would be nice if there was a
> standard register assignment on entry, for example having the physical
> address of the bi_recs in r3, but that is not essential.
>
> We should all agree on a comment set of bi_rec tags and the format for
> each type of entry.  And I like Ben's suggestion of keeping the bi_recs
> around.

Both is fine for me...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A failure will not appear until a unit has passed final inspection.

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

Re: boot methods

[Albert D. Cahalan]

I think it is important to allow for fast booting.
That means both full boot and unsuspend. There should
be a minimum of overhead on an embedded system.

As far as I'm concerned:

The kernel just appears in memory, MMU off, at address zero.
The hardware can handle this. (example: the motherboard chips
know to pull the kernel out of a serial EEPROM)

The kernel might be expected to start from address 0x100 after
a hard reset. There shouldn't be any need to create all sorts
of data structures in memory just to boot the kernel. When the
motherboard says "go", you're at 0x100 without a stack pointer.
You start with "nop ; nop ; isync ; nop" and load the MSR.

Memory might be cleared already, including BSS. It would be
bad to waste time clearing memory that is already cleared,
so memory clearing should be optional.

Uncompressing is bad. Even if I wish to use compression, I may
prefer to have a ROM or service processor handle the job.
Copying is bad too. It would be nice to get boot times down
to well under a second.

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

Re: boot methods

[Tom Rini]

On Mon, Nov 05, 2001 at 01:26:42AM -0500, Albert D. Cahalan wrote:

> I think it is important to allow for fast booting.
> That means both full boot and unsuspend. There should
> be a minimum of overhead on an embedded system.

We should make sure that the system allows for this, but not go and
implement it like this by default.  In the cases where we _need_ to be
up and running to point X in Y seconds, you do need to do things
slightly differently.  You can make sure that things are cleared, MMU is
off, et al.  What I've sort-of been thinking of for PPCBoot applies to
this case as well.  We'd have a 'wrapper' which basically converts a
bd_t if existing (since we will probably want to do this anyhow, PPCBoot
or not), and make up bi_recs for things like CONFIG_CMDLINE, if given.
Then, if needed (compile time) uncompress and jump.

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

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

Re: boot methods

[Wolfgang Denk]

Dear Ben,

in message <20011015213734.24146@smtp.adsl.oleane.com> you wrote:
>
> No, I want to get rid of bt_t. There will be a bi_rec for clocks,
> one for cmd line, etc... and possibly all sort of custom bi_recs
> you want for your boards.
>
> Any bit of kernel can then do a find_birec(type) type call to get
> the bi_rec it wants at any time.

OK. Sounds fine to me.

> Ok, time to write things down ;) I'm not sure we even all have the
> same ideas in mind as the bi_rec scheme constructed on the result of
> numerous discussions on mailing lists and irc.

Thanks - I apologize that I'm insisting on some "formal" description,
but I feel it's important enough to make sure everybody  has  exactly
the same understanding.

> But we don't want kernels & bootloader to rely on it. The bootloader
> must behave as if it was talking to a wrapper (which does the unzip
> operation in most cases) so that any interface chance we may want
> to add can go to that wrapper.

I would like to ask to make the unzip part optional.

> non native ways (that is a firmware not doing bi_recs). The goal is
> to have the code for converting the firmware interface to bi_recs
> be kept in the wrapper and not in the kernel.

Agreed.

> >- which functions are _required_ in all cases by the wrapper?
>
> Any knowledge specific to the low level firmware interface should stay
> there. We eventually wanted to have the unzipping function there as
> well, which also implies the relocating in cases the kernel can be
> loaded at a different address than 0.

Please do NOT make  the  unzip  part  a  required  operation  in  the
wrapper!  This  may  be  a  convenient thing to do in many cases, but
there are other  situations;  in  some  embedded  systems  which  are
optimized  for  minimal  boot time after power-on I don't have enough
time to uncompress an image - I must be able to boot an  uncompressed
kernel as well.

And if the firmware knows how to uncompress an image - why  should  I
duplicate the code in the wrapper?


Also, the design should NOT require that the wrapper and  the  kernel
are linked against each other in any way.

> I think the point isn't clear for everybody about the embedded case
> as we mostly deal with evil firmwares ;) The above is my view of it,
> and what I intend to code in the 2.5 timeframe. Other people may have
> other views I didn't understood or didn't agree with ;) Ultimately,
> Paulus will decide what will get in.

Well, you can count on my vote for your  proposal  if  it  should  be
asked for. It makes sense to me.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
      Bugs are by far the largest and  most successful class of
      entity, with nearly a million known species. In this res-
      pect they outnumber all the other  known  creatures about
      four to one.  -- Professor Snope's Encyclopedia of Animal

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

Re: boot methods

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> All of the 7xx/74xx/8240 boards in _devel boot via zImage.<board> from
> network/disk/flash, depending.

Except those that boot via ppc-linux-boot. Adirondack can boot only via ppc-
linux-boot and has no zImage in any shape or form, K2 can boot either via
StarMON/ppc-linux-boot or via PMON/zImage.

MS

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

Re: boot methods

[Tom Rini]

On Fri, Oct 12, 2001 at 05:32:34PM +1000, Paul Mackerras wrote:

> I would like to make a complete list of the methods people use to boot
> the PPC/Linux kernel on different platforms.  As a start, here is what
> I can think of off the top of my head:

All of the 7xx/74xx/8240 boards in _devel boot via zImage.<board> from
network/disk/flash, depending.

[snip]
> Along those lines, I have been thinking that it would be good if the
> wrapper built a data structure describing the hardware in the system,
> particularly things like:
>
> - the amount of RAM and any holes
> - type and register addresses for PCI host bus adaptors
> - ditto for interrupt controllers
> - interrupt mapping

One thing we have to keep in mind is what's required and what's
optional.  On some machines like pmac, we have a nice firmware that sets
everything up for us and is rather 'nice' to talk with.  On other boards
things are setup just enough by the firmware that we can load some bits
and with luck fix firmware 'issues' (see simple/head.S).  If we have to
find out things like RAM size from the piggyback loader, it's going to
bloat it a good deal.  We'd need, roughly to throw in mpc10x_common.c
into both the piggyback and the kernel.

If we want to keep all of this information around after init, it
wouldn't be hard to fill out the struct I suppose..

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

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

Re: boot methods

[Paul Mackerras]

Tom Rini writes:

> On Fri, Oct 12, 2001 at 05:32:34PM +1000, Paul Mackerras wrote:
>
> > I would like to make a complete list of the methods people use to boot
> > the PPC/Linux kernel on different platforms.  As a start, here is what
> > I can think of off the top of my head:
>
> All of the 7xx/74xx/8240 boards in _devel boot via zImage.<board> from
> network/disk/flash, depending.

Would you mind enumerating them for me?  I would like to have a list
of the various embedded boards we support in _devel together with the
value of <board> in the zImage filename, plus what software is used to
load that into memory.

Thanks,
Paul.

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

Re: boot methods

[Tom Rini]

On Sat, Nov 03, 2001 at 12:13:10PM +1100, Paul Mackerras wrote:
> Tom Rini writes:
>
> > On Fri, Oct 12, 2001 at 05:32:34PM +1000, Paul Mackerras wrote:
> >
> > > I would like to make a complete list of the methods people use to boot
> > > the PPC/Linux kernel on different platforms.  As a start, here is what
> > > I can think of off the top of my head:
> >
> > All of the 7xx/74xx/8240 boards in _devel boot via zImage.<board> from
> > network/disk/flash, depending.
>
> Would you mind enumerating them for me?  I would like to have a list
> of the various embedded boards we support in _devel together with the
> value of <board> in the zImage filename, plus what software is used to
> load that into memory.

I this this is mostly correct.  Any of the following, I'm pretty sure,
can also have it thrown in via a BDI.

Vendor			Extension		How
IBM Spruce		.spruce			???
Force PowerCore		.pcore			PowerBoot (Force firmware)
Force PowerPMC 250	.pcore			PowerBoot
M.E.N. F1		.menf1			??? (Probably custom fw).
Motorola LoPEC		.pplus/.bugboot[1]	PPCBUG
Motorola MCPN765	same			same
Motorola MVME5100	same			same
Motorola PrPMC750	same			same
Motorola PrPMC750	same			same
Motorola Sandpoint	.sandpoint		DINK32
SBS Adirondack	- Uses runlnx, no in-kernel booting bits
SBS K2			.k2			pmon
Zynx 4500		.zx4500			??

Why is the how important?  With the exception of firmware-deficiencies,
the current wrapper doesn't really care what it came from.  And they
usually don't provide much in the way of information about the board
(along the lines of how OF does).

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

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

Re: boot methods

[Matt Porter]

On Fri, Nov 02, 2001 at 06:55:47PM -0700, Tom Rini wrote:
>
> On Sat, Nov 03, 2001 at 12:13:10PM +1100, Paul Mackerras wrote:
> > Tom Rini writes:
> >
> > > On Fri, Oct 12, 2001 at 05:32:34PM +1000, Paul Mackerras wrote:
> > >
> > > > I would like to make a complete list of the methods people use to boot
> > > > the PPC/Linux kernel on different platforms.  As a start, here is what
> > > > I can think of off the top of my head:
> > >
> > > All of the 7xx/74xx/8240 boards in _devel boot via zImage.<board> from
> > > network/disk/flash, depending.
> >
> > Would you mind enumerating them for me?  I would like to have a list
> > of the various embedded boards we support in _devel together with the
> > value of <board> in the zImage filename, plus what software is used to
> > load that into memory.
>
> I this this is mostly correct.  Any of the following, I'm pretty sure,
> can also have it thrown in via a BDI.

That's true.  Used often on DINK32 that provides no netboot facility.

> Vendor			Extension		How
> IBM Spruce		.spruce			???

						IBM ROM Monitor

> M.E.N. F1		.menf1			??? (Probably custom fw).
						MENMON
--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

Re: boot methods

[Wolfgang Denk]

In message <20011102185547.B29932@cpe-24-221-152-185.az.sprintbbd.net> you wrote:
>
> Vendor                Extension               How
> IBM Spruce            .spruce                 ???
> Force PowerCore       .pcore                  PowerBoot (Force firmware)
> Force PowerPMC 250    .pcore                  PowerBoot
> M.E.N. F1             .menf1                  ??? (Probably custom fw).
> Motorola LoPEC        .pplus/.bugboot[1]      PPCBUG
> Motorola MCPN765      same                    same
> Motorola MVME5100     same                    same
> Motorola PrPMC750     same                    same
> Motorola PrPMC750     same                    same
> Motorola Sandpoint    .sandpoint              DINK32

also: Sandpoint         .PPCBoot		PPCBoot


> SBS Adirondack        - Uses runlnx, no in-kernel booting bits
> SBS K2                .k2                     pmon
> Zynx 4500             .zx4500                 ??

add:

  "CU824" Board (8240)
  Microsys Electronics	.PPCBoot		PPCBoot

  MOUSSE Board (8240)	.PPCBoot		PPCBoot

  EVB64260 (74xx)	.PPCBoot		PPCBoot

> Why is the how important?  With the exception of firmware-deficiencies,
> the current wrapper doesn't really care what it came from.  And they

...or there is no wrapper at all.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
You are only young once, but you can stay immature indefinitely.

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

Re: boot methods

[Tom Rini]

On Sat, Nov 03, 2001 at 10:45:37AM +0100, Wolfgang Denk wrote:
> In message <20011102185547.B29932@cpe-24-221-152-185.az.sprintbbd.net> you wrote:
> >
> > Vendor                Extension               How
> > IBM Spruce            .spruce                 ???
> > Force PowerCore       .pcore                  PowerBoot (Force firmware)
> > Force PowerPMC 250    .pcore                  PowerBoot
> > M.E.N. F1             .menf1                  ??? (Probably custom fw).
> > Motorola LoPEC        .pplus/.bugboot[1]      PPCBUG
> > Motorola MCPN765      same                    same
> > Motorola MVME5100     same                    same
> > Motorola PrPMC750     same                    same
> > Motorola PrPMC750     same                    same
> > Motorola Sandpoint    .sandpoint              DINK32
[snip]

[1]: .bugboot is for images in flash.

> > Why is the how important?  With the exception of firmware-deficiencies,
> > the current wrapper doesn't really care what it came from.  And they
>
> ...or there is no wrapper at all.

But that's going to be much of an option.  I think we want to enforce
some wrapper, so that things like PPCBoot aren't effected by internal
changes.  And I don't think the PPCBoot wrapper needs to be all that big
either.  I do need to sit down and verify this, but a PPCBoot wrapper
could be as minimal as taking a current bd_t structure and converting it
to bi_recs.  No duplicated serial, et al.

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

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

Re: boot methods

[Wolfgang Denk]

In message <20011103081553.C29932@cpe-24-221-152-185.az.sprintbbd.net> you wrote:
>
> changes.  And I don't think the PPCBoot wrapper needs to be all that big
> either.  I do need to sit down and verify this, but a PPCBoot wrapper
> could be as minimal as taking a current bd_t structure and converting it
> to bi_recs.  No duplicated serial, et al.

I think we'll implement it the other way round: as soon  a  there  is
any  definition  of  the  intended interface we will make PPCBoot use
bi_recs directly, and provide an (optional) bd_t interface for compa-
tibility with old systems.

[We already have to support two interfaces right now: one with clocks
in MHz, the other in Hz. It's not exactly nice, but it works.]

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
There is nothing in this world constant but inconstancy.      - Swift

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

Re: boot methods

[Mark A. Greer]

Tom Rini wrote:

> I this this is mostly correct.  Any of the following, I'm pretty sure,
> can also have it thrown in via a BDI.
>
> Vendor                  Extension               How

>
> Zynx 4500               .zx4500                 ??

boots out of flash


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

Re: boot methods

[Tom Rini]

On Tue, Nov 06, 2001 at 09:59:57AM -0700, Mark A. Greer wrote:
> Tom Rini wrote:
>
> > I this this is mostly correct.  Any of the following, I'm pretty sure,
> > can also have it thrown in via a BDI.
> >
> > Vendor                  Extension               How
>
> >
> > Zynx 4500               .zx4500                 ??
>
> boots out of flash

But for the 'How' column, it's a home-grown firmware, yes?

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

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

Re: boot methods

[Mark A. Greer]

Tom Rini wrote:

> On Tue, Nov 06, 2001 at 09:59:57AM -0700, Mark A. Greer wrote:
> > Tom Rini wrote:
> >
> > > I this this is mostly correct.  Any of the following, I'm pretty sure,
> > > can also have it thrown in via a BDI.
> > >
> > > Vendor                  Extension               How
> >
> > >
> > > Zynx 4500               .zx4500                 ??
> >
> > boots out of flash
>
> But for the 'How' column, it's a home-grown firmware, yes?

yes.

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

Re: boot methods

[Michael Sokolov]

Paul Mackerras <paulus@samba.org> wrote:

> I would like to make a complete list of the methods people use to boot
> the PPC/Linux kernel on different platforms.  As a start, here is what
> I can think of off the top of my head:

Here's my addition:

PPCStar (PPC hardware + VAX soul):
	vmlinux.bin loaded by the console at 0 and started by runlnx.
	vmlinux.bin.gz loaded by the console, decompressed and started by
		runlnx.
	vmlinux (ELF, .bin, or .bin.gz) booted from disk (ext2fs) by linboo.

MS

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

boot methods

[Paul Mackerras]

I would like to make a complete list of the methods people use to boot
the PPC/Linux kernel on different platforms.  As a start, here is what
I can think of off the top of my head:

Powermac:
	vmlinux loaded with BootX
	vmlinux loaded with quik
	vmlinux loaded with yaboot
	vmlinux.coff loaded via OF netboot
	vmlinux.elf-pmac loaded via OF (disk or net boot)

RS/6000 CHRP:
	vmlinux loaded with yaboot
	zImage.chrp-rs6k loaded via OF netboot

RS/6000 43p-140:
	zImage.prep loaded via OF (floppy or hard disk)

Can others contribute entries to this list please?

I am particularly interested in the cases where the kernel vmlinux
binary is loaded directly from some external software, because those
are the cases that constrain our freedom to choose how information
gets passed in to the kernel.  From a long-term maintainability
viewpoint, it would be better if we could say that we always have a
zImage-style wrapper, because then we could change the interface
between the wrapper and the kernel at will without breaking anything.
It would then be up to the wrapper to do any translation needed
between what the external software passed in to it and what the kernel
is expecting.

Along those lines, I have been thinking that it would be good if the
wrapper built a data structure describing the hardware in the system,
particularly things like:

- the amount of RAM and any holes
- type and register addresses for PCI host bus adaptors
- ditto for interrupt controllers
- interrupt mapping

The open firmware device tree does a good job of describing things
like this, so I would suggest it as the structure.  Whatever structure
we use needs to be flexible and open-ended rather than only describing
a fixed set of things, as well as being easy to traverse and
interpret (so I don't think prep-style residual data is an option).

Thoughts?

Paul.

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

Re: boot methods

[Geert Uytterhoeven]

On Fri, 12 Oct 2001, Paul Mackerras wrote:
> I would like to make a complete list of the methods people use to boot
> the PPC/Linux kernel on different platforms.  As a start, here is what
> I can think of off the top of my head:

    [...]

> Can others contribute entries to this list please?

CHRP LongTrail: arch/ppc/chrpboot/zImage loaded via OF (floppy, hard disk, CD,
...)

I _think_ this is arch/ppc/boot/images/zImage.chrp these days, but I really
have to verify (Tom? What about your LongTrail?).

Yesterday evening I just powered on my LongTrail again, after 43 days of
downtime due to marriage, honeymoon, moving, etc.  The rest of my home network
still has to be revived... I just hope no one broke LongTrail support during
the past few months :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: boot methods

[Wolfgang Denk]

In message <15302.40082.869098.88039@cargo.ozlabs.ibm.com> you wrote:
>
> I would like to make a complete list of the methods people use to boot
> the PPC/Linux kernel on different platforms.  As a start, here is what
> I can think of off the top of my head:
...
> Can others contribute entries to this list please?

The following systems are supported by PPCBoot:

## MPC8xx Systems
#########################################################################

	ADS860		AMX860		CCM		cogent_mpc8xx
	ESTEEM192E	ETX094		FADS823		FADS850SAR
	FADS860T	FLAGADM		FPS850L		GENIETV
	GTH		hermes		ICU862		IP860
	IVML24		IVMS8		LANTEC		lwmon
	MBX		MBX860T		NX823		pcu_e
	RPXlite		SM850		SPD823TS	SXNI855T
	TQM823L		TQM850L		TQM855L		TQM860L

## PPC4xx Systems
#########################################################################

	ADCIOP		AR405		CANBT		CPCI405
	CPCIISER4	CRAYL1		DASA_SIM	ERIC
	OCRTC		PIP405		WALNUT405

## MPC8240 Systems
#########################################################################

	CU824		MOUSSE		Sandpoint8240

## MPC8260 Systems
#########################################################################

	cogent_mpc8260	hymod		MPC8260ADS	PM826
	RPXsuper	rsdproto	sbc8260		TQM8260

## MPC74xx Systems
#########################################################################

	EVB64260

> I am particularly interested in the cases where the kernel vmlinux
> binary is loaded directly from some external software, because those

That's what PPCBoot does.

> are the cases that constrain our freedom to choose how information
> gets passed in to the kernel.  From a long-term maintainability
> viewpoint, it would be better if we could say that we always have a
> zImage-style wrapper, because then we could change the interface
> between the wrapper and the kernel at will without breaking anything.

But that would just shift  the  problem  from  the  kernel  into  the
wrapper:  you'd still need a standard way to pass information between
the firmware and  the  wrapper.  I  don't  see  where  there  is  any
improvement, then.

> Along those lines, I have been thinking that it would be good if the
> wrapper built a data structure describing the hardware in the system,
> particularly things like:
>
> - the amount of RAM and any holes
> - type and register addresses for PCI host bus adaptors
> - ditto for interrupt controllers
> - interrupt mapping

The bi_record discussion comes to mind. Is this what you are thinking
of? As soon as such an interface is well defined we  will  make  sure
that it is directly supported by PPCBoot, too.

> Thoughts?

There have already been several rounds of  similar  discussions,  but
AFAIK  they  all  ended  with  just  a  declaration  of  intend to do
"something,  sometime".  Is  your  proposal  a  follow-up  to   these
discussions, or a new approach?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"I've finally learned what `upward compatible' means. It means we get
to keep all our old mistakes." - Dennie van Tassel

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

Re: boot methods

[Paul Mackerras]

Wolfgang Denk writes:

> The following systems are supported by PPCBoot:

Am I right in thinking that you are the author of PPCBoot?

> But that would just shift  the  problem  from  the  kernel  into  the
> wrapper:  you'd still need a standard way to pass information between
> the firmware and  the  wrapper.  I  don't  see  where  there  is  any
> improvement, then.

There is improvement because you can have a separate wrapper for each
firmware, if necessary.  At present if we want to change the way
information is passed into the kernel, we have to synchronously change
several different firmware/booter implementations, which are
maintained in separate places by separate people.  The list includes
(at least) BootX, miboot, yaboot, PPCBoot, and Michael Sokolov's VAX
console.  This is a logistical nightmare.  Just getting the updates
into the firmware/booters is bad enough, but then you create problems
for users who then can't boot old kernels with the new firmware or new
kernels with the old firmware.

I know that if you are the firmware author, it seems easy to you to
change the firmware and install a new version.  But please look at it
from the users' point of view.

The thing about the wrappers is that they are all maintained in the
one tree along with the kernel.  If we want to make a change to the
interface between the wrappers and the kernel we can easily do that in
a coordinated fashion, without creating any compatibility problems -
old kernels naturally use the old wrapper and new kernels use the new
wrapper.  The wrapper can provide any translation necessary between
what the firmware passes in and what the kernel expects.

> The bi_record discussion comes to mind. Is this what you are thinking
> of? As soon as such an interface is well defined we  will  make  sure
> that it is directly supported by PPCBoot, too.

That's great, but I wonder what happens when someone upgrades their
PPCBoot to your new version and then wants to boot the old 2.4.2
kernel that they have lying around to check whether it shows a
particular problem they're chasing.

> There have already been several rounds of  similar  discussions,  but
> AFAIK  they  all  ended  with  just  a  declaration  of  intend to do
> "something,  sometime".  Is  your  proposal  a  follow-up  to   these
> discussions, or a new approach?

The reason that nothing has been done is precisely because it is so
hard at present to change the way that information is passed into the
kernel, because we still boot the vmlinux directly in some situations.

I am speaking from bitter experience here.  As another example, we
wanted to change the structure used to represent the OF device tree
node in the kernel.  We couldn't because that structure was also
passed in from BootX, not without implementing a translation layer.

If we absolutely *have* to boot a vmlinux directly without a wrapper,
then probably the best thing is to use bi_recs and pass in a pointer
to them, since that is reasonably flexible and can be made to be
forwards and backwards compatible without too much pain.  Changing to
this scheme is going to cause considerable pain in the short term,
though.

Paul.


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

Re: boot methods

[Wolfgang Denk]

Dear Paul,

in message <15304.9109.488577.697206@cargo.ozlabs.ibm.com> you wrote:
>
> Am I right in thinking that you are the author of PPCBoot?

No exactly: PPCBoot is an Open Source project and has many roots  and
authors; but I'm coordinating all the efforts.

> The thing about the wrappers is that they are all maintained in the
> one tree along with the kernel.  If we want to make a change to the
> interface between the wrappers and the kernel we can easily do that in
> a coordinated fashion, without creating any compatibility problems -
> old kernels naturally use the old wrapper and new kernels use the new
> wrapper.  The wrapper can provide any translation necessary between
> what the firmware passes in and what the kernel expects.

That's fine. But there other things to keep in mind, too:

* Especially with embedded systems  the  memory  footprint  is  often
  critical.  Adding an extra bootstrap loader which includes it's own
  versions of functions like serial console driver and de-compression
  code is just wasted memory.

  In systems where a reliable remote software upgrade must be guaran-
  teed you might find even more than one kernel image in the system -
  then the effect of this waste of memory multiplies.

* When porting Linux to new hardware the wrapper adds  an  additional
  layer which must be adapted and ported. If you have PPCBoot running
  on  a  board,  all  that's  needed to "port" Linux to that board is
  copying things like ethernet intialization from the PPCBoot sources
  - since PPCBoot is based on Linux device driver  code,  this  is  a
  simple copy & paste.

* With PPCBoot, you can use the same kernel image on different boards
  without need to recompile it just because you want differend  default
  boot arguments.

* With PPCBoot, you can use the same kernel image in combination with
  different ramdisk images without need to recompile it.

Etc. etc. It was one of our design goals with PPCBoot to get  rid  of
all the (IMHO) unneccessary maintenance of the bootstap loader code.


I can understand that the wrappers make sense for  boards  that  come
with  some  firmware that cannot or shall not be changed; but this is
the only reason I see for it's existence.


Your argumentation sounds as if you expect many frequent  changes  of
the kernel boot interface. Is that true? In sucha case I'd suggest we
spend some more thoughts on that interface before changing it.

> That's great, but I wonder what happens when someone upgrades their
> PPCBoot to your new version and then wants to boot the old 2.4.2
> kernel that they have lying around to check whether it shows a
> particular problem they're chasing.

This is not the first incompatible change we've  seen:  for  instance
the  switch  from passing the clock frequencies in HZ (instead of MHz
as it was before Patch 1.1.1.6) is such an incompatible change of the
kernel interface.

We will deal with it.

> If we absolutely *have* to boot a vmlinux directly without a wrapper,
> then probably the best thing is to use bi_recs and pass in a pointer
> to them, since that is reasonably flexible and can be made to be
> forwards and backwards compatible without too much pain.  Changing to

It was my assumption from the  previous  discussions  that  this  was
going  to  happen. I like it because you have the option to chose the
implementation that fits best: if a wrapper seems appropriate it  can
be  used  easily; if another solution seems simpler this can be used,
too. Enforcing want to be forced to use of a wrapper  in  all  cases.
want.

> this scheme is going to cause considerable pain in the short term,
> though.

I don't see much difference to the status quo: f or all  the  systems
using  a  wrapper  it is a transparent change like any other; for the
other systems it's a new, incompatible  kernel  interface  just  like
what happened with the Mhz / Hz change.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"We don't care.  We don't have to.  We're the Phone Company."

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

Re: boot methods

[Benjamin Herrenschmidt]

>
>* When porting Linux to new hardware the wrapper adds  an  additional
>  layer which must be adapted and ported. If you have PPCBoot running
>  on  a  board,  all  that's  needed to "port" Linux to that board is
>  copying things like ethernet intialization from the PPCBoot sources
>  - since PPCBoot is based on Linux device driver  code,  this  is  a
>  simple copy & paste.

No. When porting to new hardware, you expect your bootloader to pass
the proper bi_recs your kernel need and your wrapper will be either
empty, or just the standard one. In some case, I expect a same
kernel could even work with a wide range of boards as base addresses
and config for some legacy drivers could be passed via bi_recs as well.

The goal of bi_rec's here is to replace bd_t with a tagged structure.

One thing I want here is to stop parsing the bi_rec's once for all in
the kernel, but on the contrary keep them available all the time a bit
like the device-tree. For custom boards like the one(s) I'm working for
this is a flexible mecanism for my firmware to pass some HW informations
to the kernel, which stays the same for the whole range of products.

>* With PPCBoot, you can use the same kernel image on different boards
>  without need to recompile it just because you want differend  default
>  boot arguments.

Which is also what the bi_recs will help do in a more generic way.
The point of the wrapper is to handle firmware that don't already pass
the bi_recs we need, or more "interactive" firmwares like OF.

>* With PPCBoot, you can use the same kernel image in combination with
>  different ramdisk images without need to recompile it.

I don't see the problem neither. Our proposed mecanism won't replace
bootloaders like ppcboot.

>Etc. etc. It was one of our design goals with PPCBoot to get  rid  of
>all the (IMHO) unneccessary maintenance of the bootstap loader code.
>
>
>I can understand that the wrappers make sense for  boards  that  come
>with  some  firmware that cannot or shall not be changed; but this is
>the only reason I see for it's existence.

It handles whatever translation is needed between the firmware and the
kernel. If your firmware (ppcboot) already pass in good shaped birecs
and no translation is needed, just use an empty (or no) wrapper.
>
>Your argumentation sounds as if you expect many frequent  changes  of
>the kernel boot interface. Is that true? In sucha case I'd suggest we
>spend some more thoughts on that interface before changing it.

>> That's great, but I wonder what happens when someone upgrades their
>> PPCBoot to your new version and then wants to boot the old 2.4.2
>> kernel that they have lying around to check whether it shows a
>> particular problem they're chasing.
>
>This is not the first incompatible change we've  seen:  for  instance
>the  switch  from passing the clock frequencies in HZ (instead of MHz
>as it was before Patch 1.1.1.6) is such an incompatible change of the
>kernel interface.
>
>We will deal with it.
>
>> If we absolutely *have* to boot a vmlinux directly without a wrapper,
>> then probably the best thing is to use bi_recs and pass in a pointer
>> to them, since that is reasonably flexible and can be made to be
>> forwards and backwards compatible without too much pain.  Changing to
>
>It was my assumption from the  previous  discussions  that  this  was
>going  to  happen. I like it because you have the option to chose the
>implementation that fits best: if a wrapper seems appropriate it  can
>be  used  easily; if another solution seems simpler this can be used,
>too. Enforcing want to be forced to use of a wrapper  in  all  cases.
>want.
>
>> this scheme is going to cause considerable pain in the short term,
>> though.
>
>I don't see much difference to the status quo: f or all  the  systems
>using  a  wrapper  it is a transparent change like any other; for the
>other systems it's a new, incompatible  kernel  interface  just  like
>what happened with the Mhz / Hz change.
>


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

Re: boot methods

[Wolfgang Denk]

In message <20011015124214.18780@smtp.adsl.oleane.com> you wrote:
> >
> >* When porting Linux to new hardware the wrapper adds  an  additional
> >  layer which must be adapted and ported. If you have PPCBoot running
> >  on  a  board,  all  that's  needed to "port" Linux to that board is
> >  copying things like ethernet intialization from the PPCBoot sources
> >  - since PPCBoot is based on Linux device driver  code,  this  is  a
> >  simple copy & paste.
>
> No. When porting to new hardware, you expect your bootloader to pass
> the proper bi_recs your kernel need and your wrapper will be either
> empty, or just the standard one. In some case, I expect a same
> kernel could even work with a wide range of boards as base addresses
> and config for some legacy drivers could be passed via bi_recs as well.

No what? I don't see any discrepance in yout statement and  mine.  We
will  switch  to  bi_rec's without complaining once the interface has
been defined.

> The goal of bi_rec's here is to replace bd_t with a tagged structure.

That's fine for me.

> One thing I want here is to stop parsing the bi_rec's once for all in
> the kernel, but on the contrary keep them available all the time a bit

What does that mean? You want to replace the old  bd_t  by  bi_rec's,
and  then  add  a  wrapper that parses tthe bi_rec's and builds a new
bd_t type stucture, just to be able to easily change the bd_t layout?

> Which is also what the bi_recs will help do in a more generic way.
> The point of the wrapper is to handle firmware that don't already pass
> the bi_recs we need, or more "interactive" firmwares like OF.

Agreed.

> I don't see the problem neither. Our proposed mecanism won't replace
> bootloaders like ppcboot.

Ummm... I'm sorry, but I seem to be missing something.  What  exactly
is  your "proposed mechanism"? I haven't seen any real proposals yet.
The statements I've seen so far are not clear at all.

You write "your wrapper will be either empty, or  just  the  standard
one".  Dan  Malek  wrote  "we  keep  suggesting a piggyback loader is
always used rather than trying to boot vmlinux (or compressed version
of it) directly" (mind that he talks about a LOADER,  which  probably
includes a lot more functions than a wrapper that just satisfies some
interface conversion).

Can you please explain:

- which interface will there be between the firmware and the "wrapper"?
- which interface will there be between the Linux kernel and the "wrapper"?
- which functions are _required_ in all cases by the wrapper?

> It handles whatever translation is needed between the firmware and the
> kernel. If your firmware (ppcboot) already pass in good shaped birecs
> and no translation is needed, just use an empty (or no) wrapper.

This would be perfectly fine to me - but  it  sounds  different  from
what I hear from others.


Please understand me: I don't oppose the change,  on  contrary:  I've
been  bitten  often  enough  by  the  limitations of the current bd_t
stuff. I want to get rid of it as soon as  possible.  But  so  far  I
haven't  seen  a  clear  proposal,  nor  seen  any  code.  I  got the
impression that different people have very differenti deas of what is
going to happen, and I'm just trying to find out  to  whom  I  should
listen ;-)

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
To the systems programmer,  users  and  applications  serve  only  to
provide a test load.

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

Re: boot methods

[Michael Schmitz]

> Powermac:
> 	vmlinux loaded with BootX
> 	vmlinux loaded with quik
> 	vmlinux loaded with yaboot
> 	vmlinux.coff loaded via OF netboot
> 	vmlinux.elf-pmac loaded via OF (disk or net boot)

vmlinux(?) loaded with miboot (used by Debian boot-floppies for some
machines)

	Michael


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

Re: boot methods

[Juergen E. Fischer]

Hi Paul,

On Fri, Oct 12, 2001 at 17:32:34 +1000, Paul Mackerras wrote:
> RS/6000 43p-140:
> 	zImage.prep loaded via OF (floppy or hard disk)

and OF netboot (at least on 7043-140).


Jürgen

--
"Well, let's just say, 'if your VCR is still blinking 12:00, you don't
want Linux'".
  -- Bruce Perens

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

Re: boot methods

[Nils Krueger]

Hi Paul!

> I would like to make a complete list of the methods people use to boot
> the PPC/Linux kernel on different platforms.  As a start, here is what
> I can think of off the top of my head:

I have a Motorola PowerStack "Series E" PReP machine.

I can boot the zImage.prep from a "PPC PReP Boot" partition (type 41) having
written it to that partition using the dd command.

The PPCBug firmware has also the following options. I have only tested
booting from floppy.

- boot zImage from floppy disk, CD or tape (also directly written to it)
- network boot (tftp)

Nilz
--
http://www.hoschi.de/nilz   (Nilz' Homepage)


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

Re: boot methods

[Michel Lanners]

On  12 Oct, this message from Paul Mackerras echoed through cyberspace:
>
> I would like to make a complete list of the methods people use to boot
> the PPC/Linux kernel on different platforms.  As a start, here is what
> I can think of off the top of my head:
>
> Powermac:
> 	vmlinux loaded with BootX
> 	vmlinux loaded with quik
> 	vmlinux loaded with yaboot
> 	vmlinux.coff loaded via OF netboot
> 	vmlinux.elf-pmac loaded via OF (disk or net boot)

Hmm, vmlinux.coff floppy-booted on OldWorlds?

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: boot methods

[Michel Dänzer]

On Fri, 2001-10-12 at 09:32, Paul Mackerras wrote:
>
> I would like to make a complete list of the methods people use to boot
> the PPC/Linux kernel on different platforms.  As a start, here is what
> I can think of off the top of my head:
>
> Powermac:
> 	vmlinux loaded with BootX
> 	vmlinux loaded with quik
> 	vmlinux loaded with yaboot
> 	vmlinux.coff loaded via OF netboot
> 	vmlinux.elf-pmac loaded via OF (disk or net boot)
>
> RS/6000 CHRP:
> 	vmlinux loaded with yaboot
> 	zImage.chrp-rs6k loaded via OF netboot
>
> RS/6000 43p-140:
> 	zImage.prep loaded via OF (floppy or hard disk)

APUS:
	vmlinux loaded with boothack (from AmigaOS)


--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

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

Re: boot methods

[Peter Bergner]

: Powermac:
: 	vmlinux loaded with BootX
: 	vmlinux loaded with quik
: 	vmlinux loaded with yaboot
: 	vmlinux.coff loaded via OF netboot
: 	vmlinux.elf-pmac loaded via OF (disk or net boot)
:
: RS/6000 CHRP:
: 	vmlinux loaded with yaboot
: 	zImage.chrp-rs6k loaded via OF netboot
:
: RS/6000 43p-140:
: 	zImage.prep loaded via OF (floppy or hard disk)
:
: Can others contribute entries to this list please?

Recent addition to yaboot allows:

	zImage loaded with yaboot


Peter

--
Peter Bergner
SLIC Optimizing Translator Development / Linux PPC64 Kernel Development
IBM Rochester, MN
bergner@vnet.ibm.com


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

Re: boot methods

[Val Henson]

Gemini:
	zImage.gemini loaded with Smon

We already have a zImage wrapper to translate things between Smon
format and the current kernel format.  No constraints to freedom on
Gemini's account.

Sorry for the late response.

-VAL

On Fri, Oct 12, 2001 at 05:32:34PM +1000, Paul Mackerras wrote:
>
> I would like to make a complete list of the methods people use to boot
> the PPC/Linux kernel on different platforms.  As a start, here is what
> I can think of off the top of my head:
>
> Powermac:
> 	vmlinux loaded with BootX
> 	vmlinux loaded with quik
> 	vmlinux loaded with yaboot
> 	vmlinux.coff loaded via OF netboot
> 	vmlinux.elf-pmac loaded via OF (disk or net boot)
>
> RS/6000 CHRP:
> 	vmlinux loaded with yaboot
> 	zImage.chrp-rs6k loaded via OF netboot
>
> RS/6000 43p-140:
> 	zImage.prep loaded via OF (floppy or hard disk)
>
> Can others contribute entries to this list please?
>
> I am particularly interested in the cases where the kernel vmlinux
> binary is loaded directly from some external software, because those
> are the cases that constrain our freedom to choose how information
> gets passed in to the kernel.  From a long-term maintainability
> viewpoint, it would be better if we could say that we always have a
> zImage-style wrapper, because then we could change the interface
> between the wrapper and the kernel at will without breaking anything.
> It would then be up to the wrapper to do any translation needed
> between what the external software passed in to it and what the kernel
> is expecting.
>
> Along those lines, I have been thinking that it would be good if the
> wrapper built a data structure describing the hardware in the system,
> particularly things like:
>
> - the amount of RAM and any holes
> - type and register addresses for PCI host bus adaptors
> - ditto for interrupt controllers
> - interrupt mapping
>
> The open firmware device tree does a good job of describing things
> like this, so I would suggest it as the structure.  Whatever structure
> we use needs to be flexible and open-ended rather than only describing
> a fixed set of things, as well as being easy to traverse and
> interpret (so I don't think prep-style residual data is an option).
>
> Thoughts?
>
> Paul.
>

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